Design Systems: Open versus Closed Source

Hello! I hope you're enjoying my Design Systems series thus far, we've already talked about starting one and when it's good to build versus buy. In this article, I wanted to talk about why you should open source your Design System. In my opinion, open sourcing is a no brainer for many reasons, as long as your organization will allow it.

What is Open Source?

You may be wondering, "what do you mean by open source?". A huge majority of software out in the wild today uses at least one open source library. There are varying statistics on the internet (search "open source usage stats") about what percentage of modern software is built on open source, but it's safe to say that modern software runs on open source.

To put it plainly, open sourcing something means it is free for anyone to use as long as they follow the provided license. The license is normally written so that users are free to update, change, and distribute the software to their needs, free of charge; however, each license is different. Most open source software follows a common list, with MIT being the most open and free to use. When looking at open source libraries, be sure to check out their license.

How about "closed source"? What I mean here is the exact opposite of open source. It is entirely private code that is not shared publicly and kept internal to the organization. It makes a lot of sense to keep an organization's business logic / "secret sauce" in this realm; however, when it comes to things like Design Systems and other presentational building blocks, it makes a ton of sense to go open source (in my opinion!).

GitHub has a great page to get folks started in open source. It has a lot of great resources for folks new to the concept. I also recommend checking out the report from RedHat on open source and why enterprises prioritize those who work in open source.

Atomic Design Patterns

One of the reasons I love open sourcing a Design System is it forces you to follow atomic design patterns. When your Design System is open source, it forces you to write components that are not tied to organization-specific data or data-fetching mechanisms. Instead, you focus on providing the presentational pieces or building blocks for folks to build UI. By following atomic design patterns, your components will have less bugs, be more reusable, have better tests, and have a singular, primary focus.

As a very basic example, let's say we need to build a form that looks like below. How would you break this down into atomic, presentational components? (Go ahead and interact with the form! It also supports both light and dark modes.)

Although overly simplifying my point, this is normally how I go about building designs. My mind immediately begins breaking this form into individual building blocks. I see a wrapping form as the parent. Inside of the form is our input, textarea, and button. These are all separate, individual components - they don't need to be tied into a single "Form" component.

By open sourcing your Design System, it forces you to think at the atomic-level. Creating items as separate components allows you to use them elsewhere in your application, which leads to greater UI/UX consistency!

Public Eye

By open sourcing your Design System, anyone who has internet access can now view and interact with what you've built. I've had multiple instances when interviewing candidates where they'd mention "I looked over your Design System on GitHub". This is, at a minimum, a conversation starter when interviewing candidates. From their perspective, they also get a sense of how you write code, the pull request review process at your organization, see how tests are written and coverage, and many other benefits that give a look into how your organization operates on a day-to-day basis. I can't state enough how much open sourcing your code helps with recruiting, both for the interviewer and interviewee.

In 2018, I presented at EmberConf on Toyota's shared component library, Loom. After giving the talk, I had quite a few people ask me if it was open source and if they could see what we had built. Unfortunately at the time, it was not. This made me realize how powerful open sourcing is when talking at conferences. It's great to talk publicly about your work; however, developers really want to see the code and what problems you're solving. By open sourcing your Design System, you'll have more confidence after presenting as you can show folks exactly what you're doing by providing a link to the repository. When I signed on at LifeOmic, I ensured that we open sourced our Design System, Chroma, as early as possible for this exact reason.

GitHub Open Source Benefits

One of my favorite things about open sourcing software is all of the great tooling provided by GitHub. For most things, it's all free as well! I've highlighted some of my favorite benefits below.

GitHub Actions (CI/CD)

GitHub has Actions which cover all of your CI/CD needs. The best part is, for open source software, it's all free! As the docs say, "Build, test, and deploy your code right from GitHub". Depending on your organization, moving CI/CD from whatever you're using internally to GitHub means more cost savings for your organization as it's less time and resources spent running them on your machines.

Publishing a Documentation Site

I highly recommend building a documentation site or using something like storybook to document your Design System. With the help of a few external providers, you can also publish your docs site for free via GitHub as well. You could use GitHub Pages, but some of my favorite external providers to use are Vercel, Cloudflare Pages, or Netlify. Deploying to any of the mentioned providers above are all done via GitHub Actions.

Once again, your organization is saving money by not having to host and deploy the documentation site.

Test Matrices

One item I learned recently from a friend, NullVoxPopuli, is setting up test matrices. By using test matrices you can now test against many different versions of dependencies in parallel. At CrowdStrike, we test against many different versions of TypeScript, as well as many different versions of Ember in our test steps. This essentially allows us to ensure we are backwards and future compatible.

Visual Regression Testing

From a high level, the way visual regression testing works is it detects visual changes when someone creates a pull request. As an example, say someone changes the background color of a primary button from blue to purple. This would be flagged as a visual change. It creates a snapshot of what's currently "in production" versus what the incoming changes are and displays an image comparing the two side-by-side. Someone on your team must approve the new, incoming visual changes before the pull request can be merged. If you don't approve the changes, the pull request is blocked. Once the pull request is merged, the new image is set as the baseline going forward.

If you're working in a Design System, you'll be paying close attention to how things are represented visually. Instead of doing this work manually, why not let computers do it for you? If your Design System is open sourced, you can take advantage of visual regression testing tools like Percy or Chromatic. They have free plans if your project is open sourced on GitHub. Yet another cost savings item for the organization with a huge benefit for your team!

Open Source if Possible

Overall, I highly recommend open sourcing your Design System. The benefits of open sourcing are huge! It helps you write better components by following atomic design patterns, it opens the door for recruiting and conference talks by allowing you to show what you're working on in public, it allows you to use excellent, modern tooling from the open source community, and it'll save your organization a lot of money on CI/CD resources. Thanks for sticking with me on this article. I hoped you enjoyed it! Hopefully catch you in my next Design Systems article!

Need help open sourcing your Design System? Feel free to contact me as I love consulting and doing contract work! I'd love to help you and your team build better software. ❤️