订阅内容

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.


关于作者

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
UI_Icon-Red_Hat-Close-A-Black-RGB

按频道浏览

automation icon

自动化

有关技术、团队和环境 IT 自动化的最新信息

AI icon

人工智能

平台更新使客户可以在任何地方运行人工智能工作负载

open hybrid cloud icon

开放混合云

了解我们如何利用混合云构建更灵活的未来

security icon

安全防护

有关我们如何跨环境和技术减少风险的最新信息

edge icon

边缘计算

简化边缘运维的平台更新

Infrastructure icon

基础架构

全球领先企业 Linux 平台的最新动态

application development icon

应用领域

我们针对最严峻的应用挑战的解决方案

Original series icon

原创节目

关于企业技术领域的创客和领导者们有趣的故事