The evolution of open source contributors: from hobbyists to professionals

The most recent episode of Command Line Heroes is all about the process of contributing to open source, from the point of view of a contributor and a maintainer. It's a great episode - don't just take my word for it, you can listen here - but you can only tackle so much in one episode! One thing that the episode sparked for me is just how much the nature of open source contribution has changed since Netscape first took the plunge with Mozilla in 1998.

In the past 20 years, we've seen a strong shift away from a culture of hobbyist developers tinkering with projects as they find time, to folks doing open source contribution as part of their day job. Whether that’s folks paid to work on open source full time, or people who contribute to open source as part of their day job because the project is relevant to their other work.

As open source has become more of a mainstay of just about every business, more businesses started hiring developers to ensure the success of those projects. Or they turned to companies (like, yes, Red Hat) that could support their use of open source by maintaining, improving, and even creating new projects to address business needs.

At this point, I’d wager that the vast majority of open source contributions are coming from professionals of one stripe or another, rather than hobbyists. That’s not to say that people have stopped working on open source in their spare time, or that open source is unsuitable for hobby projects. But the trope of open source as a communal, volunteer-driven activity is outdated.

Recognizing contributions of all forms

Notice how I shifted from "developers" to "contribution" earlier when talking about the shift from hobbyists to professionals? That's not an accident -- in the late 90s, projects rarely recognized the importance of non-developer contributions. Projects, like Debian or the Apache Software Foundation (ASF), that had formal roles with voting power usually wrote their criteria around code contributions of some kind. If your "only" contribution was documentation, good luck being recognized and voted into a position of influence in a project.

Today, I’m happy to say, that is much less common. Many projects, like the ASF, Debian, and Fedora have worked to acknowledge contributors who bring a wide range of skills needed to maintain a healthy open source project.

And, again, many of these folks are doing this as part of their day job. Support for open source projects as a whole - not merely the code - is understood as important to the business.

Better community management and governance

Just as projects and communities have learned that producing open source requires many skill sets beyond developing code, they’re learning that contributing to a project and governing it is a skill in and of itself. In fact, our understanding of and approach to developing open source has led to the production of entire books that codify best practices for open source development.

Working in the open requires confidence and trust. It’s one thing to send your work to a couple of peers you know well and have a relationship with, it’s quite another to send work to an open list where anyone can critique it and a person well outside your workplace has the final say of whether it’s accepted or not.

Being a good contributor takes practice. It requires learning how the project operates, perhaps a different set of tools than you’re used to - git vs. SVN, or a new bugtracker, or new Kanban tool - as well as receptiveness to feedback and willingness to adapt.

Even more difficult is being a good maintainer. An effective maintainer strives to ensure that all contributors are treated equally, and treated well. Mentoring new contributors, and handling their contributions professionally - even if they’re ultimately unused - is not unlike being a good manager.

That’s why I’m so pleased to have an episode of Command Line Heroes that addresses this topic head-on. Building our skills as contributors and maintainers is crucial to developing successful, sustainable, open source projects. Take a few minutes and listen to "Ready to Commit" today, or if you haven’t started with Command Line Heroes yet, you can start at the beginning with episode one.