Suscríbase al feed

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.

Sobre el autor

Joe Brockmeier is the editorial director of the Red Hat Blog. He also acts as Vice President of Marketing & Publicity for the Apache Software Foundation.

Brockmeier joined Red Hat in 2013 as part of the Open Source and Standards (OSAS) group, now the Open Source Program Office (OSPO). Prior to Red Hat, Brockmeier worked for Citrix on the Apache OpenStack project, and was the first OpenSUSE community manager for Novell between 2008-2010. 

He also has an extensive history in the tech press and publishing, having been editor-in-chief of Linux Magazine, editorial director of, and a contributor to, ZDNet,, and many others. 

Read full bio

Navegar por canal

automation icon


Las últimas novedades en la automatización de la TI para los equipos, la tecnología y los entornos

AI icon

Inteligencia artificial

Descubra las actualizaciones en las plataformas que permiten a los clientes ejecutar cargas de trabajo de inteligecia artificial en cualquier lugar

open hybrid cloud icon

Nube híbrida abierta

Vea como construimos un futuro flexible con la nube híbrida

security icon


Vea las últimas novedades sobre cómo reducimos los riesgos en entornos y tecnologías

edge icon

Edge computing

Conozca las actualizaciones en las plataformas que simplifican las operaciones en el edge

Infrastructure icon


Vea las últimas novedades sobre la plataforma Linux empresarial líder en el mundo

application development icon


Conozca nuestras soluciones para abordar los desafíos más complejos de las aplicaciones

Original series icon

Programas originales

Vea historias divertidas de creadores y líderes en tecnología empresarial