We should open-source our design system
Our internal design system has 40+ components, solid accessibility, and great documentation. I think we should open-source it. Benefits: recruiting signal, community contributions, forces us to maintain quality because it's public, and it's good for the ecosystem.
The main risk is maintenance burden, but we're already maintaining it internally. The incremental cost of accepting community PRs is manageable if we set clear contribution guidelines.
Comments 6
The recruiting signal is real. I chose my current job partly because I saw the team's open-source work and was impressed by the code quality. It's the best technical blog post you'll never have to write.
What license are we thinking? MIT is simple but means competitors can use it freely. Apache 2.0 gives us patent protection. This decision has real implications and shouldn't be an afterthought.
I'm very in favor of this. Even if community contributions are small, the act of making it public improves our documentation and forces us to remove internal hacks. That alone is worth it.
Legal needs to review every component for IP issues before we can publish anything. Last time we tried to open-source a small library, legal review took 4 months. Has anyone started that conversation?
Our components have hardcoded references to internal APIs and our auth system. The cleanup to make this actually open-sourceable is probably 2-3 months of work. Is the recruiting signal worth that investment?
I worked at a company that open-sourced their design system. The community contributions were minimal — maybe 5 meaningful PRs in a year. But the maintenance burden was real: issues from people using it in ways we didn't anticipate, questions about framework support we didn't offer, etc.
Themes 4
Our components have hardcoded references to internal APIs and our auth system. The cleanup to make this actually open-sourceable is probably 2-3 months of work. Is the recruiting signal worth that investment?
I'm very in favor of this. Even if community contributions are small, the act of making it public improves our documentation and forces us to remove internal hacks. That alone is worth it.
What license are we thinking? MIT is simple but means competitors can use it freely. Apache 2.0 gives us patent protection. This decision has real implications and shouldn't be an afterthought.
Legal needs to review every component for IP issues before we can publish anything. Last time we tried to open-source a small library, legal review took 4 months. Has anyone started that conversation?
I worked at a company that open-sourced their design system. The community contributions were minimal — maybe 5 meaningful PRs in a year. But the maintenance burden was real: issues from people using it in ways we didn't anticipate, questions about framework support we didn't offer, etc.
Our components have hardcoded references to internal APIs and our auth system. The cleanup to make this actually open-sourceable is probably 2-3 months of work. Is the recruiting signal worth that investment?
Legal needs to review every component for IP issues before we can publish anything. Last time we tried to open-source a small library, legal review took 4 months. Has anyone started that conversation?
I'm very in favor of this. Even if community contributions are small, the act of making it public improves our documentation and forces us to remove internal hacks. That alone is worth it.
What license are we thinking? MIT is simple but means competitors can use it freely. Apache 2.0 gives us patent protection. This decision has real implications and shouldn't be an afterthought.
The recruiting signal is real. I chose my current job partly because I saw the team's open-source work and was impressed by the code quality. It's the best technical blog post you'll never have to write.
Our components have hardcoded references to internal APIs and our auth system. The cleanup to make this actually open-sourceable is probably 2-3 months of work. Is the recruiting signal worth that investment?
The recruiting signal is real. I chose my current job partly because I saw the team's open-source work and was impressed by the code quality. It's the best technical blog post you'll never have to write.