Open Source Products versus Open Source Projects

“if you’re not paying for the product, then you are the product.” 

– Tristan Harris, Former Google Design Ethicist

I have been a maintainer, contributor, collaborator and fan of many open source projects from Apache to Eclipse to Red Hat and now GitLab.  One of the common challenges we see in open source projects is the ability to predict and release functionality on a consistent schedule with quality and security in mind.  This challenge is not unique to open source software, as many enterprise customers I work with are on a journey to move from a project driven, ticket based approach to a product driven, value based approach.  

Project driven open source projects struggle to gain the community it needs to survive because there is a lack of vision and the backlog continues to grow with little or no interaction from the maintainers ultimately leading to a project being referenced as stale or dead.  When we look at open source products, they are driven by a vision that maintainers strive to embody and choose to deliver features that map to that vision.  This allows them to comb the backlog more efficiently sharing with the community what items are in scope for future releases.  Product driven communities are more collaborative because they all agree on the theme for their work product instead of individual tasks. 

This is also critical to how you choose to participate in open source communities.  I get a lot of questions from college students that want to contribute to these projects to build out their resume.  I challenge them to think about how much time they have, what languages they have mastered and ultimately what types of products get them excited.  For me, that is the developer experience space.  I have mastered Ruby and Ruby on Rails from my time at Red Hat back in 2005 which lead to where I am today at GitLab focusing on developer experience and working with Ruby on Rails.  GitLab as an open source product has a vision to be a single platform for the entire software supply chain and that drives our releases on the 22nd of every month.  

So how do you focus on product development when you still need to manage tasks for developers to complete?  First and foremost, you need to be transparent about your plan.  You also need to plan months in advance if you expect to get community contributions as most of those people have day jobs that they must complete and you are asking for their good will to help you complete the tasks necessary to make the upcoming date.  Here is an example of how GitLab performs our asynchronous, remote contribution model.

Finally, to complete our transformation from project to product driven development, we need to establish value streams that we hold as important to the product.  The critical first step is to establish multiple boards, one board per stream for tracking purposes.  This allows us to find community members interested in specific value streams to find work items to complete based on availability towards the next milestone.  Creating labels on issues and merge requests defined as “Good First Issue/MR” allows new community members to find work items that are easier to get started with.  Now we can filter our project based on value streams to see our throughput to drive additional community membership by showing how active we are in completing work items.  If you are interested in learning more, come by the GitLab booth to learn more about how GitLab can help you get started in open source, contribute to our vibrant community of open source products or learn how to set up a community practice inside your own organization focused on value streams.

The Featured Blog Posts series will highlight posts from partners and members of the All Things Open community leading up to the conference in the fall.