Rethinking Open Source Collaboration

Rethinking Open Source Collaboration was originally published on Open Source Delivers.

The open source world has been through a significant period of change in the last fifteen years. What started out as volunteers getting together to work on projects for fun has now turned into a billion-dollar industry. Although the spotlight is shone on open source more than ever before and the technology and tools have evolved, the core fundamentals of how we build open source software are still the same at their core – yet the rigor and quality expectations have changed. I think this is a great opportunity for our wider community as well as an organization.

When I think of open source projects, I mentally categorize them into two areas:

1. Hobbyist – Hobbyist projects are software that was invariably conceived by a small number of people and are primarily maintained by volunteers. These projects are typically fairly loose in terms of project management, formalized QA/CI, and release planning and management.
2. Mission Critical – Mission critical projects are usually power fundamental pieces of infrastructure and/or other products. In these cases the software has many different stakeholders and contributors, and they typically require rigorous planning, testing infrastructure, and release management. In other words, there is a much lower buffer for error and problems due to the importance of these projects.

While it is rare for Mission Critical projects to become Hobbyist projects, it is fairly common for Hobbyist projects to become Mission Critical. With so much focus, investment, and interest in open source, I think we need to start thinking differently in how we manage all open source projects and the tools that are available to build them. This will help prime the pump in growing quality in all projects, but also help the transition of a Hobbyist project moving over to become Mission Critical.

Ten years ago, the tools for managing an open source project were pretty simple: you used SourceForge. There weren’t many other collaboration forges available, and SourceForge was by far the most commonly used.

Since then we have seen many alternatives appear; GitHub, Gitorious, Launchpad, and more. These days it seems the most common home for a codebase is GitHub.

While I have nothing against GitHub (quite the opposite, they do a wonderful job), I think we need to think about more than just code. GitHub is perfect for people who want to throw some code up somewhere with a simple README for how to use it. It is simple, quick, and effective. For larger projects where developers are collaborating around code, GitHub is also a great choice. The key point is that this is all focused on creating and landing *code*.

In thinking of that transition between a Hobbyist and Mission Critical project we need so much more though. We need communication channels, feature blueprinting tools, automated testing infrastructure, code and branch review/management tools, release planning, contributor/role management, project blogs/websites, online event management, documentation and API tools, wikis, and more.

Today the majority of major Mission Critical projects are either building their own infrastructure to fulfill these needs or cobbling a bunch of services together, all with different authentication and management systems. This seems like a missed opportunity.

I think there are hundreds of thousands of open source projects all around the world that could benefit from a central set of services that relate to (1) community management (2) planning (3) source code and bug control (4) QA and testing, and (5) promotion and advocacy. There is a great opportunity to bring together the many different pieces in the software development process (source control, bug tracking, branch management, collaborative documentation, feature planning, CI, automated testing, etc), and then to build a sensible and straight-forward workflow that enables any project to either use a subset of the tools or all of them. This will fulfill the needs of Hobbyist or Mission Critical projects, or anything in-between.

There are a number of benefits of this. Firstly, no-one is really providing that end-to-end solution today. Secondly, I think a number of open source projects would move to this platform to prevent them having to set up their own infrastructure. Thirdly, it would give the organization that runs this an edge in the market. Fourth, this service could become a center of innovation where the very best technology is being built, and finally, I think the overall quality of open source would be improved due to the availability of better tools and commonly understood workflow.

Importantly, delivering this would require much more than simply cobbling together the pieces. The service would need to feel slick and integrated and with a simple path for projects to move over from existing services.

The central hub of development here could also open up other opportunities in terms of people pulling together different tools to create platforms and products, providing a central place to find the coolest stuff (think Freshmeat but brought up to date), and in some cases, methods of monetizing projects to help support further development and resourcing (e.g. attending conferences and buying hardware).

Of all the organizations working in this space, I think SourceForge (powered by the tremendous Apache Allura) has the most potential here. SourceForge has a long heritage of pulling together a platform for software development, and I think the company has an opportunity to bring their offerings (and their brand) up-to-date, particularly in a culture where GitHub is popular for providing one piece of this overall picture (code hosting).

The impact of this could not just make it easier for developers to create software, but it could have a transformative effect on the quality and recognition of open source as a whole, causing more Hobbyist projects to become Mission Critical.