Tag Archives: open-source

Becoming an ASF Committer

I’ve been mentoring some folks at work who want to become committers in various ASF communities, and wrote the following as part of trying to document that advice.

Note that I’ll likely update this article periodically to reflect edits on my internal version of this doc. Your feedback would be very helpful in that process, as I try to help my colleagues be better upstream citizens.

Disclaimer

Nothing in this post should be construed as a guarantee. You can do everything listed here, for years, and still not become a committer. This is because the decision is made by individuals on the project PMC, who do things for their own reasons.

On the contrary, this document discusses how things should work, and sometimes do work, in some Apache Software Foundation (ASF) projects, but might not on the one you’re interested in.

Beneath each of these recommendations is the assumption that you are acting in good faith, for the benefit of the project. Simply attempting to check these boxes to game the system will reflect badly on you, and probably on your employer, too.

Becoming a Committer

It’s important to remember that becoming a committer is not a reward, or a recognition, so much as that it is the project expressing self-interest. That is, people are added as a committer to a project because it benefits the project, not because it’s some kind of pat on the back for the individual in question. As such, every behavior suggested here is about advancing the interests of the project. It is critical that you think, first and foremost, about being a project owner, and working towards the benefit of the project and its users.

These, therefore, are the behaviors that you should exhibit if you want to become a committer, and then a PMC member, on an ASF project. (These are not unique to ASF projects, of course, but process will differ greatly from one project to another, and are largely similar among ASF projects.)

Read the mailing list

ASF projects communicate on the mailing list. If you want to be involved in the community, you must set aside time every week (preferably every day) to keep current on the community discussion.

When first participating in an ASF project, you can (and should) look back several months (or as far as you have time for) to see what has been discussed recently. You can do this at http://lists.apache.org/

A growing number of projects also have a presence on Slack, Discord, or somewhere else. Find where that is, and become a regular. A shrinking number of projects have a presence on Libera IRC – mostly the much older projects. This is where you’ll connect with the older members of the projects and learn more of the ancient project lore.

Contribute code (and other things)

If you want to become a committer, you should make significant contributions to the project. The most obvious thing to contribute to a software project is code. Code contributions should be diverse in terms of size and significance. That is, you should work on small issues and large. You should collaborate with others on features and fixes, and you should propose significant changes yourself. You should dig up old tickets, and work towards resolving them.

In particular, you should work on code that is of benefit to all users, rather than focusing solely on features that benefit only yourself, or your employer. As a project owner, you should care about the entire health and sustainability of the project.

Code contributions are not the only type of contribution that counts towards becoming a committer, it’s just the most common. Design, documentation, marketing, event management, and many other ways of contributing to the success of a project are also often considered in making someone a committer. While the term “committer” implies committing code, it can also be interpreted as someone who is committed to the project.

End user support

Answering end user questions has many benefits. It’s the best way to establish expertise in aspects of the software that effect actual users, and, thus, the best way to stay in touch with user concerns. It’s also the way to establish and maintain visibility in the project community, because your name is always visible on the mailing list.

Caution: Do not just jump in and answer every question with visibility as a primary goal. Ensure that your answers are actually useful, and contribute something to the conversation. Simply posting to every conversation, particularly when someone else has already offered a good answer, can be perceived as attempting to game the metrics.

Documentation

Improving the documentation is one of the most effective things that one can do to improve the user experience. If you notice many people asking similar questions, this is usually an indication that the documentation is weak on that point. Fix it. When the question is asked again, point to the improved documentation, and ask for feedback as to how it could be further improved.

Take criticism of the documentation as a challenge, rather than a personal criticism.

Review PRs and tickets

Dig into unmerged PRs and outstanding tickets. Figure out how to navigate the process to get an old ticket resolved, or a PR merged.

This is an investment in the project in two ways.

The obvious improvement is getting an issue fixed or a PR merges, thus enhancing the project. The less obvious way is that ancient tickets, and unmerged PRs, communicate that the project is not actively maintained, and that user issues are being ignored. This undermines project trust. Thus, addressing these things builds community trust, and increases your personal value to the project.

Be visible

Participate meaningfully in discussions on the developer mailing list. Drive discussions through to action. Advocate for changes that help yourself and your employer, but also for those that improve the project as a whole.

Get to know the important characters on the project, and what their priorities are. Help them achieve those priorities in whatever way you can. Figure out who you can best collaborate with to advance your own personal interests in the project, but also the overall health of the project and community.

Start conversations around topics you’re passionate about, and volunteer to be the one to address them.

Do not, however, just talk to be seen. Nobody is fooled by that.

Vote on releases (non-binding)

Vote on release candidates and releases (non-binding).

Note that a vote should always mean that you’ve actually tested, so testing releases is implied here, too. Indicate what platform(s) you’ve tested on, and what was the nature of the tests that you performed. Testing releases on a variety of platforms and configurations is a very valuable piece of information for projects with limited testing infrastructure.

While these votes don’t “count” towards making a release official, it’s both hugely beneficial for the project, and increases your visibility.

Give talks

Propose talks to conferences about the project, and about how your employer’s customers are using it.

Proposing “Introduction to Apache Woobly” talks has many benefits. It is a great way to get the word out about the project. It’s good for establishing yourself as an expert in the field. It educates users (and potential customers) about operating the software. And it will help you identify what’s actually important about the software, how people use it, and what kinds of questions real users are asking about the software.

ApacheCon is the obvious place to give these talks, but also look for conferences about the general technology space around the project you’re contributing to.

Once you’re a committer …

If and when you achieve your goal of becoming a committer, don’t consider your journey done.

Becoming a PMC member is a continuation of the same path. Continue to do all of the above things, focusing more on the health of the project as a whole, rather than just your personal interests, or those of your employer or manager.

Also, take an active interest in other contributors – both those on your team, and those with other employers. Mentor them in following the same path that you followed. Encourage them. Celebrate them, and mention them to other contributors. This is an investment in the future of the project, so that, some day, when you move on to something else, the project will live on.

Interest across multiple projects, and at the Foundation-wide level, is the start of the path to becoming a Foundation Member, if that is something that interests you.

Summary

Finally, a reminder – there’s no way to guarantee promotion to committer or the PMC. However, if you make your goal the improvement of the project, rather than just about personal promotion, and approach these recommendations as a path to project ownership, in good faith, these are your best path towards that goal.

Resources

Find your project’s committer and PMC membership lists at https://projects.apache.org/

Read mailing list archives at https://lists.apache.org/

Find your contribution count to date on Github, for example: https://github.com/apache/hadoop/graphs/contributors (You can drag a date range to narrow it down to recent contributions.)

View past board reports from your project at https://www.apache.org/foundation/board/calendar.html This is a good way to judge the rate at which a given project adds committers and PMC members. It’s also a way to compare how long other individuals took to attain committer status.

Open Source Glossary

When discussing open source with colleagues, I tend to assume that they already know the basics. But, as open source becomes a standard part of all software development, and the number of people working with open source grows, this has become less and less true.

What follows is a minimal viable vocabulary, which I’m posting here so that I can link to it elsewhere when having these conversations, and attempting to assume a lingua franca.

Open Source

Open source refers to software which is developed and released under an OSI (Open Source Initiative) approved license. Open source licenses are those that comply with the Open Source Definition, which sets forth ten tenets which are mandatory components of a compliant license.

Within these tenets, there is a lot of room for variation, and thus there are many licenses that qualify as open source licenses, ranging from extremely permissive (“Do whatever you want with this code.”) to much more restrictive (“You must do these things with the code.”)

While, strictly speaking, “open source” is a legal definition of the license under which software is released, it also implies a project which is run under the guidelines of the Four Opens – Open Source, Open Design, Open Development, and Open Community. In reality, most projects fall short of that ideal in some way, but it is an ideal to be striven for.

Fork

A fork is a copy of an open source project, for the purpose of making changes to the source code. Usually, this is done with the intention of offering those changes back to the original (“upstream”) project for inclusion in future versions (See “PR/MR/Patch”)

A private fork is when this copy is made privately, inside a particular company or organization, without visibility to the upstream.

A public fork, as the name indicates, is done in public where everyone on the project can see what changes are being proposed. This is always preferable, as it allows the project community to comment and participate in these changes, rather than them being a surprise.

A hostile fork is when a project is forked with no intention to ever contribute back, but, rather, to continue to run a competing project indefinitely. This should be considered only in the most extreme of situations.

PR/MR/Patch

A PR (Pull Request), MR (Merge Request) or Patch, are all terms for offering a change back to the originating project (“upstream”), for inclusion in future versions of that project. The terms indicate different ways that the change may be submitted, but all refer to essentially the same thing – a proposed change.

A PR is the desired end-game on any fork. Forks should be short-lived, and have a specific proposed change in mind, rather than being long-running or permanent artifacts.

Upstream

An upstream project refers to the open source project from which you are building. That implies the existence of a downstream – a project, product, or service which inherits some or all of its code from that upstream. For example, Apache Kafka is the upstream for Amazon Managed Streaming for Apache Kafka (MSK). (Which, of course, implies that MSK is the downstream from Apache Kafka.)

The upstream/downstream relationship is symbiotic. That is, a project relies on users, and a product or service relies on the upstream’s health and sustainability. As such, a downstream product or service should do everything in its power to support and sustain the project which it depends on. And project, in their turn, should listen to customers and users, and be responsive to them.

Maintainer

A maintainer is someone empowered to make changes to an open source project, and/or to make releases of that project. Ideally, a healthy project will have multiple maintainers, and there will be healthy discussion and debate around changes that go into a project.

Single-maintainer projects, or single-vendor projects (ie, where all maintainers come from the same vendor/company/organization) pose a risk to the sustainability of that project, since the change in direction from one source can result in the user community being suddenly disenfranchised or surprised. Thus, it is an ideal of open community that there be a diversity of inputs in the pool of maintainers, to ensure that all voices are equally heard when changes are made.

No, inclusive language is not NewSpeak

The Inclusive Naming initiative is an effort to remove language from software which creates an unwelcoming community. Words like ‘slave’, for example, are used extensively in software, when other words are both more meaningful and less problematic.

When I discuss this effort, by far the most common response that I get from detractors is that it’s Orwellian – that it is NewSpeak – that it is erasing words and forbidding subversive thought.

In Orwell’s book 1984, NewSpeak is a state-approved modification to language that uses vague, euphemistic words, when the clearer, more accurate word is deemed bad.

This is quite literally the opposite of what we are trying to do with the INI and related conscious language efforts. Instead, we are trying to replace metaphors like ‘slave’ with words that accurately describe what is happening in the software, while at the same time removing the association with the horrifying history of actual slavery in the real world.

The ideal that we are somehow forbidding the use of the word ‘slave’, in this example, is equally untrue. The word slave has a meaning, and a historical context, and should be used to reflect that meaning and context. Using ‘slave’ to refer to a database replica, for example, not only has these overtones from *actual slavery*, it also doesn’t accurately describe what is happening in database replication, which is confusing.

Technical documentation should avoid idiomatic phrases, colloquialisms, and metaphor, whenever possible, and should always strive to choose the word or phrase that describes the function or feature in the most unambiguous way possible. Words and phrases such as slave, blacklist, insane, and so on, not only violate that rule, but do it in a way that is likely to make segments of the population feel unwelcome or “othered“, which is the antithesis of community building.

Women in Open Source

I’ve been thinking about the topic of women in open source for quite some time. For context, the percentage of women in IT is about 20%, and the percentage of women in open source is about 1.5%. For larger context, read Skud’s OSCon keynote, because she is *way* better at articulating it than I am.

Which brings me to my point.

The women I know in open source are way above average. By which I mean, quite simply, that almost all of them make me feel stupid by comparison.

Now, I don’t consider myself a genius, but I also know that I’m no dunce. I’ve written 13 books. I can read several languages, and make myself understood in one or two of them. I have a masters degree in mathematics. I’m no slouch.

But then I look at people like Skud, Allison Randall, Noirin Shirley, and Elizabeth Naramore, among others, and feel like maybe I should have paid more attention in school.

But, see, if I look around all of the Open Source projects that I’m involved with, *all* of the women are this caliber. There are no average or below-average women in Open Source, it seems. Which makes me look at some of Skud’s statistics, and wonder.

Sure, men are unaware of the problem, because they look around and see these amazingly talented women working with them, and figure, how can there be a problem.

But that seems to only highlight the problem. Why’s that? Well, apparently, when you’re a woman, you have to be amazing just to get past all of the old-boys-club and macho chauvinism that pervades the entire Open Source culture. Granted, this is less true in some corners of the kingdom than others, but it’s pretty prevalent where I live.

I remember riding up to my hotel room (at a conference) in an elevator with my wife, and a PHP developer who, fortunately, I don’t know the name of, wearing a shirt that was so profoundly offensive and degrading to women that it was all I could do to not make him apologize right there. Perhaps I should have. And that’s certainly not a one-off anecdote.

Now, I don’t pretend to know what the solution is. But I think that a good way to start is reading Skud’s presentation, and not wearing shirts like that – not only at conferences, but ever. Until we men adjust our attitudes about women, we’re going to perpetuate this problem – even if we refuse to acknowledge that it’s a problem.

Right place at the right time

Jim blogged about the PHP credits list, and so I took a look. I was amazed to notice that of all the people listed, I know at least half of them, and have met most of the others. I’ve been very lucky to be in the right place at the right time, and meet some amazing people, and get associated with a pretty amazing organization, and by extension, a bunch of others.

In the early days, when the term Open Source wasn’t quite as well known as it is now, I managed to meet a significant number of the folks responsible for Perl, and become friends with several of them. A few years later I started spending more time with Apache than with Perl, and that’s developed into speaking opportunities, books, interesting projects – but most importantly and lastingly, a bunch of friends.

Every now and then, I get a glimpse of just how lucky I’ve been over the last ten years, and the truly astonishing opportunities that have been available to me by virtue just being in the right place, and being willing to volunteer a little of my time.

I’ve been less involved for the last year, since there’s somewhere that my attention has needed to be focused. I’m gradually getting back into spending time on Apache things, but it’s given me some time to think about where I want to spend the few cycles that I have, and I expect that my involvement will be a little different from what it’s been in the past.

But time will tell.