Abonnez-vous à notre blog

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.


À propos de l'auteur

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 Linux.com, and a contributor to LWN.net, ZDNet, UnixReview.com, and many others. 

Read full bio

Parcourir par canal

automation icon

Automatisation

Les dernières nouveautés en matière d'automatisation informatique pour les technologies, les équipes et les environnements

AI icon

Intelligence artificielle

Actualité sur les plateformes qui permettent aux clients d'exécuter des charges de travail d'IA sur tout type d'environnement

open hybrid cloud icon

Cloud hybride ouvert

Découvrez comment créer un avenir flexible grâce au cloud hybride

security icon

Sécurité

Les dernières actualités sur la façon dont nous réduisons les risques dans tous les environnements et technologies

edge icon

Edge computing

Actualité sur les plateformes qui simplifient les opérations en périphérie

Infrastructure icon

Infrastructure

Les dernières nouveautés sur la plateforme Linux d'entreprise leader au monde

application development icon

Applications

À l’intérieur de nos solutions aux défis d’application les plus difficiles

Original series icon

Programmes originaux

Histoires passionnantes de créateurs et de leaders de technologies d'entreprise