Tag Archives: asf

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.

No, Apache did not send you spam

Today, the ASF received yet another complaint from a distraught individual who had, in their opinion, received spam from the Apache Software Foundation. This time, via our Facebook page. As always, this is because someone sent email, and in that email is a link to a website – in this case, www125.forcetwo.men , which is displaying a default (ie, incorrectly configured) Apache web server, running on CentOS.

This distraught individual threatened legal action against the ASF, and against CentOS, under FBI, Swedish, and International law, for sending them spam.

No, Apache didn’t send you spam. Not only that, but Apache software wasn’t used to send you spam. Unfortunately, the spammer happened to be running a misconfigured copy of software we produced. That’s the extent of the connection. Also, they aren’t even compentent enough to correctly configure their web server.

It would be like holding  a shovel company liable because someone dug a hole in your yard.

Or, better yet, holding a shovel company liable because someone crashed into your car, and also happened to have a shovel in their trunk at the time.

We get these complaints daily, to various email addresses at the Foundation, and via various websites and twitter accounts. While I understand that people are irritated at receiving spam, there’s absolutely nothing we can do about it.

And, what’s more, it’s pretty central to the philosophy of open source that we don’t put restrictions on what people use our software for – even if they *had* used our software to send that email. Which they didn’t.

So stop it.

 

ApacheCon NA 2015, day 1

It’s only 8:30 local time, but I’m pretty wiped out. Day one has been amazing.

The morning started with the keynotes, which included the State of the Feather, with Ross Gardler, two sponsor keynotes by Mike Maxey (Pivotal), and Chip Childers (Cloud Foundry), and then the main opening keynote by Brian Behlendorf. Brian has long been someone that I’ve really looked up to, not just because he catalyzed the Apache web server project, but because of the deep thought that he’s given to issues around Open Source, community, and our role as responsible members of the human race. (Videos coming soon of all these keynotes.)

Right after the keynote, I moderated what I’ve been referring to as the “grey beard panel”, where several members of the original Apache Group (Jim Jagielski, Dirk-Willem  van Gulik, Randy Terbush, Brian Behlendorf, Roy Fielding, and Ken Coar) reminisced about how things were in the early days, what mistakes were made, what things they might have done differently (SSL was a big item on this list), and other related items.

I’ve long joked that I do ApacheCon so that I can travel to exciting places and hang out on stage with my heroes. This was definitely one of those moments.

In the afternoon I gave my “Write a Better FM” talk, which is a continually evolving thing. Rikki said some very encouraging things about it. In all, I think it went really well.

Then we had the reception at Old School, which was very nice, if a little loud. And now I’m back in the hotel room trying to decide whether to catch up on email, or go seek out some more social -ness. Probably go with the former and go to bed early.

 

ApacheCon Budapest 2014

1 Comment

15811606055_5637e3d709_zLast week, the Apache Software Foundation, with the help of the Linux Foundation event team, hosted ApacheCon Europe in lovely Budapest, Hungary at the gorgeous Corinthia hotel.

If my count is right, this was the 24th event to bear the name ‘ApacheCon’, and the 8th time we’ve done it in Europe. Also, we were celebrating the 15th anniversary of the Apache Software Foundation, which incorporated in June of 1999.

Every ApacheCon has its own set of memories, from Douglas Adams pacing the stage in London, to the ApacheCon Jam Sessions in Dublin, to the Segway tours in San Diego, to the funeral march in New Orleans. And Budapest was no different – a wonderful event with lots of great memories.

On Sunday night, I had dinner with the TAC’ers. The Apache Travel Assistance Committee is a program by which we get people to ApacheCon who could otherwise not afford to be there. This is critical to the mission of the ASF, because it builds the community in an inclusive way, rather than limiting it to people with the funds to travel. TAC recipients have to give back a little – they provide session chair services, introducing speaker and counting attendees. A large percentage of our former TAC recipients have become deeply involved in the ASF, more than paying off the investment we make in them.

Although I didn’t try the Tripe And Trotters on the buffet line, I did enjoy great conversation with old friends and new ones around the table.

15813169492_0cd44f034e_z

Monday morning, I opened the conference with the State Of The Feather keynote – our annual report on what the ASF has done with sponsor dollars and volunteer time over the last year, and some thoughts about where we’re going in the next 15 years. The latter is, of course, very difficult in an organization like the ASF, where projects, not the Foundation leadership, make all of the technical decisions. However, David Nalley, the VP of Infrastructure, had some pretty specific ideas of what we have to do in terms of Infrastructure investment to ensure that we’re still able to support those projects, which are being added at about 1.5 a month, for the next 15 years and beyond.

15820067232_75991115c0_zAfter the State of the Feather, I had the enormous privilege to stay on the stage with Hugh Howey to discuss the parallels between self publishing and open source software development. I’ve got another blog post in the works specifically about that, so stay tuned, and I’ll add a link here when it’s ready. Any day that starts with me hanging out on stage with a favorite author in front of 300 of my closest friend is a good day.

Once the sessions started, everyone went their separate ways, and I gave several talks about the Apache httpd project. httpd has been my main focus at Apache for 15 years, and although it’s faded into the background behind more exciting projects like Spark, Hadoop, CloudStack, Solr, and so on, it’s still the workhorse that powers more than half of the websites you’ll ever see, so there’s always a decent audience that turns out to these talks, which is very gratifying.

One of my talks was more focused on the business of doing documentation and “customer support” in the open source world. My “RTFM? Write a better FM!” talk discusses the RTFM attitude that exists in so many open source software communities, and how destructive it to the long term health of the projects. I’ve got another blog post in the works specifically about that, too, and I’ll add a link here when it’s ready.

Tuesday and Wednesday were a whirlwind of sessions, meetings – both formal and informal, and meals with friends, colleagues, and newly-met conference attendees. As a board member, I’d sometimes get pulled into project community discussions to offer the board’s perspective on things. As conference chair, there we numerous discussions about the upcoming event – Austin, Texas, April 13-17 – and the next Europe event – stay tuned, announcement coming soon!

Session highlights during the week include:

  • Shane Curcuru’s talks on trademarks, copyrights, and protecting the Apache brand.
  • Jesus Barahona’s talk about the statistical analysis work he’s done for Cloudstack, and other projects, and how it can be used to support and encourage community growth.
  • Pierre Smits’ case study talk about OFBiz and beer, which I missed because I was speaking at the time, but which I heard was amazing.
  • Joe Brockmeier’s talk about Docker, which was apparently the best-attended talk of the entire event.

Although we didn’t record the talks this year (if you’re interested in sponsoring that for next time, get in touch – rbowen@apache.org), you can see the slides for most of these talks on the conference website.

15816582111_4b19b886c5_zOn Monday night we had a birthday cake for the ASF, and I got all emotional about it. The ASF has been hugely influential in so many aspects of my life, from my amazing friends to my amazing job, and it’s such an honor to serve the Foundation in the capacity of conference chair. I look forward to the next 15 years and seeing where we go.

And then, so fast, it was Wednesday evening. David Nalley gave his keynote about the value of the Apache Software Foundation. While I was expecting a number – something like 3 trillion dollars or something – instead, he talked about the many ways that the ASF adds value to companies, to individuals, and to the world as a whole. A truly inspiring talk, and it made me incredibly proud to be associated with the ASF. Bror Salmelin then talked about the Open Innovation 2.0 project at the European Commission to close out the formal portion of our event.

The lightning talks were a big hit this time around, with a great mix of serious and lighthearted talks, all in five minutes or less, MC’ed by the inimitable Joe Brockmeier.

15647039319_0624e084ce_z

On the whole, I was very pleased with this conference. If there’s anything that disappointed me about the conference, it’s only the number of old friends who couldn’t make it. I hope that everyone who couldn’t make it to Budapest is able to come to Austin to celebrate the 25th ApacheCon, and the 20th anniversary of the first release of the Apache HTTP Server!

 

[Note: Some of these photos are mine, and are on Flickr. Some of them are from the Linux Foundation, and are also on Flickr.]

ApacheCon North America 2014

Last week I had the honor of chairing ApacheCon North America 2014 in Denver Colorado. I could hardly be any prouder of what we were able to do on such an incredibly short timeline. Most of the credit goes to Angela Brown and her amazing team at the Linux Foundation who handled the logistics of the event.

My report to the Apache Software Foundation board follows:

ApacheCon North America 2014 was held April 7-9 in Denver, Colorado, USA. Despite the very late start, we had higher attendance than last year, and almost everyone that I have spoken with has declared it an enormous success. Attendees, speakers and sponsors have all expressed approval of the job that Angela and the Linux Foundation did in the production of the event. Speaking personally, it was the most stress-free ApacheCon I have ever had.

Several projects had dedicated hackathon spaces, while the main hackathon room was unfortunately well off of the beaten path, and went unnoticed by many attendees. We plan to have the main hackathon space much more prominently located in a main traffic area, where it cannot be missed, in Budapest, as I feel that the hackathon should remain a central part of the event, for its community-building opportunities.

Speaking of Budapest, on the first day of the event, we announced ApacheCon Europe, which will be held November 17-21 2014 in Budapest. The website for that is up at http://apachecon.eu/ and the CFP is open, and will close June 25, 2014. We plan to announce the schedule on July 28, 2014, giving us nearly 4 months lead time before the conference. We have already received talk submissions, and a few conference registrations. I will try to provide statistics each month between now and the conference.

As with ApacheCon NA, there will be a CloudStack Collaboration Conference co-located with ApacheCon. We are also discussing the possibility of a co-located Apache OpenOffice user-focused event on the 20th and 21st, or possibly just one day.

We eagerly welcome proposals from other projects which wish to have similar co-located events, or other more developer- or PMC-focused events like the Traffic Server Summit, which was held in Denver.

Discussion has begun regarding a venue for ApacheCon North America 2015, with Austin and Las Vegas early favorites, but several other cities being considered.

I’ll be posting several more things abut it, because they deserve individual attention. Also, we’ll be posting video and audio from the event on the ApacheCon website in the very near future.

Fun at the ASF

After wading through another 100+ message thread on the Apache Software Foundation members list, I wanted to make several observations.

I’m still having an awful lot of fun working on the Apache HTTP Server project. The ability to contribute to a project that is used by tens of millions of websites is pretty cool, and is my small way of making the world a better place.

There are many valid philosophies of Open Source (or, if you prefer, Free Software) development. The Apache Way isn’t for every project. But it happens to be what makes sense to me. I think it builds strong communities that are based on code and not on ego, and that people come away from them with a well-developed ability to mentor other developers who are just getting started in Open Source, while many models that focus on one individual lead to folks who expect that hand-holding in the next project, too.

Some of the coolest people I know, I met through the ASF. Some of the other coolest people I know I met through PHP and Perl, but the ones that I consider friends are almost all in the ASF. And, in the end, life is more about relationship than changed lines of code.

There are some very cool projects within the ASF that a lot of people just don’t know about that. While my effort to rectify this via FeatherCast has been … ahem … less than successful, I still get to talk to some amazing people. And, yes, I have two interviews that I need to finish editing and push out. Sorry for the slowness. We’re doing some innovative things at Apache, and it continues to be frustrating that all people think about is the web server when they hear Apache.