At the beginning of 2016, as the team behind Project Clarity started the initial work, our main goal was for Clarity to fill a gap within VMware. Clarity was to provide a layer of common visual language that will bring designers and engineers together as well as serve as a common layer of consistency across all of VMware’s user interfaces.
It was an ambitious mission that needed us to work with dozens of teams and hundreds of engineers and designers across the company to understand their use cases and needs, as well as advocate for what we believed is the future of user experience for VMware’s web-based applications.
Even though we thought on day one about the idea of open sourcing Project Clarity, open sourcing it wasn’t our top priority at the time. It didn’t make sense to open source a project that is yet to provide any success for our internal products. We needed to prove ourselves first before we’re ready to share our work with the world and before we’re able to advocate for others teams within other companies to adopt Clarity.
One of the core principles that we’ve held from day one as we worked on Clarity internally was the importance of making other products that are built on top of Clarity successful. Our success wasn’t in the success of how much work we would be able to do or how many releases we’ll be able to ship. Our success is going to be tied to the success of the products which depended on Clarity to deliver modern, well-designed, and well-thoughtout design system.
This is a risky idea. We’ve basically put our success in the hands of our consumers vs. basing it on the technological success of our framework.
As we worked closely with dozens of teams across VMware, we realized that we’re already somewhat open source. We were just “open source” within VMware. We were already working with dozens of teams, hundreds of engineers and designers, and dozens of different (and difficult) use cases around the same problem we’re trying to solve. This realization has helped us on our path to open sourcing Clarity.
On November 15th of last year, we decided to take the official step of open sourcing Clarity. The response has been overwhelmingly positive and we couldn’t be happier with the work we’ve been able to do since then with the community we’ve built around Clarity.
Our core principle of building our success on top of the success products and teams building on top of Clarity are having remains true. We believe in “product-based open source development” which is fancy talk for: working with real products to build real open source projects.
We believe in the importance of seeing Clarity actually helping engineers and designers do their work better, faster, and have better results for their teams and companies.
We continue to believe in working with teams across the industry to build modern, well-designed, and well-engineered experiences that delight customers (both VMware and otherwise).
One aspect that continue to be a challenge that we’re working through is the priority of requirements between “internal” VMware projects and “external” open source consumers.
As we grow in the open source community, more requirements continue to land in our issue tracker on GitHub and via all other communication tools. We work hard to solve all the problems that we run across, but prioritization is key when running an open source project. What we’ve figured out as a solution so far is to do a few things:
- Prioritize based on the vision of Clarity vs. the type of project requesting a feature or asking us to fix an issue. Being an external or internal project doesn’t play much in our decision in comparison to the issue itself and how it serves our vision.
- The more an issue is requested by different teams and products, the more we look into it. It is important to listen to the engineers and designers using Clarity and the more of them working on different products that are telling us we have an issue or need to change or add something, the more the chance they’re absolutely right.
- We work with our teams inside of VMware as well as contributors externally to continue to encourage contributions. We need another blog post here to talk about quality control in contributions but we love our community and want to encourage more of Clarity to come from that community.
- We’re open and honest about what’s next, and about our thoughts. We’ve shared our roadmap, we post our design and technical spec before we move into implementation, and we engage the community in our decisions to make sure we’re arriving at solutions that solve real problems.
- We release and plan a release every week. This has been really important in making sure we can shift priorities when needed. Solve critical bugs almost immediately, and research problems in smaller chunks of times so we’re able to provide real results quickly.
We do many other things in the background as well to make sure we continue to operate efficiently and in the open but maybe that’s for another post.
So far, we’ve been enjoying “product-based open source development” but we’d definitely love to hear from you. Tell us how Project Clarity has been working for your open source project; connect on GitHub, follow us on medium.com or join us on Twitter.
