How to "bus-proof" your open source project

[This was first published on 10/5/2006. I'm putting all of the articles I've published on here so that I'll have one place I can look for all of them.]

People often talk about a software project's bus factor -- the number of people on your project that need to get hit by a bus to leave you with no one familiar with your codebase. In the open source world, the disappearance of even one developer can herald the death of your project -- if you don't prepare in advance.
The most important thing you can do to bus-proof your project is to attract a strong developer community for it. Since open source developers usually first get involved in a project as users, you need to attract users for your project. This means that you need to create something that people want to use and then listen carefully to the user feedback -- today's user may turn out to be tomorrow's release manager.

Start by creating something that people want to use. If you create a project to scratch a particular itch, you may attract a few contributors, but unless it's something that people actually use, it will succumb to bit rot after the initial itch is scratched. Interest in something built only for its own sake can only last so long.

You'll usually work on a project that people (namely you) want to use, and your project will attract a community of users and developers, with people fixing patches and making suggestions. If you want to keep these users around, you need to keep your project in good working order. That means vetting bug reports, fixing bugs, and working on new features. Regardless of the technical level of your project's users, odds are that they see your project differently than you do, so it may take a lot of dialog to understand a user's bug report or feature request. It can be a lot of work to translate a user's feedback into something that a developer can make sense of. But listening to your users, fixing bugs that they report, and paying attention to their feature requests will keep them coming back to use your software, and in many cases make them some of your biggest proponents. They'll usually wind up bringing you -- yep, you guessed it -- more users.

Now, to be clear, I'm not advocating that you spend your valuable time fixing every tiny bug and implementing every whimsical feature that a user requests. But before your project has grown to more than 10 or 15 developers, it's usually in your best interest to at least let your users know that they've been heard. Even if your email is only to let them know that you likely won't be implementing their pet feature, you let them know that you're listening by responding to them (and drop their requests into your issue tracker so they won't get lost).

As your project attracts more users, you'll inevitably pick up the odd developer (and believe me, some of them will be odd) as part of the community that you're building around your project. The first you'll usually hear from a potential new developer is in the form of a patch to fix an existing (often trivial) bug -- be it a code bug or a minor documentation fix. Users that show up on a development discussion list with patch in hand merit careful attention, because if you determine that their patch is a good patch and you apply it promptly, you could wind up with the ongoing attention of another project contributor, and attention is the common coin of the open source world. If this new developer is clueful, understands your project and the direction you're taking it, and keeps submitting patches, you'll find yourself wanting to let him just commit their own work. If you offer him commit access to your project as soon as you determine that he'll make a good team member, he'll usually stick around for a while to help you with your project.

Now you've got a project with a thriving user community and a small community of developers. You start to dream of a large castle with your minions bowing before you, paying homage to your greatness as a project leader, making offerings of Amazon wishlist items and PayPal donations.

Stop. Right. There.

Running your project with an iron fist is no way to increase your project's bus factor -- specifically, your bus factor.

Life changes can have a drastic effect on the amount of time that you can put into your project. You might get married or have a child. If you don't have a job, you might get one. You might get hit by a bus (or a meteorite) or contract a terminal disease or, heaven forbid, actually lose interest in your project.

Relinquish control.

Build a community of developers who make decisions by consensus and you'll have a project community that is not only lacking a single human point of failure, but that has the flexibility to lose one or more committers either temporarily or permanently. This kind of community allows developers to take turns leading the project (as much as you can "lead" a project run by consensus) and is remarkably robust as developers depart and return to contribute as their time allows. This is the true hallmark of a long-lived, productive open source project.

There are many other things that you can do to make your open source project successful, but by maintaining interest, paying attention to your users, and building a strong community, you're well on your way to developing a project that will grow for years to come. Best of all, you can stop panicking every time you see an oncoming bus on the way to lunch.

Author's note: Thanks to Karl Fogel and C. Michael Pilato for reading drafts of this article.

Apache, Open Source, and the Small Software Company

[This was first published on 05/30/2005. I'm putting all of the articles I've published on here so that I'll have one place I can look for all of them.]

The Apache Software Foundation is one of many open source software organizations shaking the business world all the way down to its proprietary software toes. Along with Linux, the Apache HTTP Server has long been the consummate example of the power and quality of open source software. Its runaway success against Microsoft IIS illustrates that the better product can triumph over both monopoly and marketing dollars.

Today, most small software development companies are acutely aware of the advantages of collaborating on open source software; at the very least, they're aware of the high costs of writing and maintaining closed-source software. With so little to be gained by writing and maintaining commodity software components (e.g., a Web server, a relational database, or an operating system), many companies are finding it cheaper to use and contribute bugfixes to an existing open source product than to start from scratch.

While the Apache Software Foundation (ASF) started as a group of Webmasters who just wanted a decent Web server to help them do their job, it has since become home to dozens of successful software projects with thousands of contributors and millions of lines of code. In fact, the ASF currently has the largest collection of active open source Java projects owned by a single organization.

The ASF accepts only individuals - not companies - as members and committers; however, many companies pay developers to work on ASF projects part- or full-time. This isn't because these companies are inherently altruistic, but because they've realized that it's cheaper to pay one or two developers to maintain and fix bugs on an open source project than to pay a team to maintain a closed-source equivalent in-house.

Large and small companies alike ignore open source software at their own peril. Years ago, "Not Invented Here" described a corporate state of mind that dutifully avoided using any solution not developed "in-house" - you had to either build it or buy it. Today, using "Not Invented Here" software is practically a requirement. Who wants to reinvent a Web server? Or an XML parser? Or a servlet container? But with open source, there's another choice in addition to "build it or buy it": get it for free.

Amidst all of this upheaval, the role of the developer has changed as well. Gone are the days when a development team can lock themselves in a closed room and knock out an application written from scratch over the course of a year. Companies need developers who are more archaeologist and assembler than fabricator. The smart, small company needs people with the ability to wade through the thousands of open source projects, find the gem with a stable codebase and an active community, and build on it.

The ASF understands that the long-term viability of an open source project is directly tied to the community that develops and maintains it. As a result, ASF projects are organized around communities and not only codebases. Sourceforge.net is a great example of why it's not all about the code - a bit of research reveals that close to 80% of the projects that reside there lie dormant. It's a testament to the number of open source software projects that go by the wayside every year. Many projects that exist are attempting to solve the same problem in a slightly different way, and software is subject to the process of natural selection. The strongest projects survive, the weaker ones combine or die out, and you're left with a better piece of software in the end.

Even though open source software has its idiosyncrasies, small development shops are gaining more power from it than ever. By building applications out of premade components, a modicum of glue code, and as little of their own code as possible, software companies are saving money and bringing products to market faster than ever. Developers spend less time reinventing wheels and more time concentrating on solving business needs. Leveraging open source saves licensing money at the outset, but the true win comes further down the road from the savings on maintainability.

As the ASF grows, it continues to work to ensure the long-term viability of its projects. And open source software continues to change the way that companies think about software solutions as well as the way they build their software. Leveraging open source drives the cost of development down, shortens the time-to market, and improves the quality of the software built on it. Gone are the days of having to choose between good, fast, and cheap - with open source software, companies can have all three.

Painting the Bikeshed at BSDCan 2007

Ben and I spoke at BSDCan last weekend up in Ottawa and had a great time hanging out with the FreeBSD folks. One of the cool surprises at the conference, was that we met Poul-Henning Kamp. The Subversion project has been talking about his famous bikeshed post for years now, and Ben and I make explicit mention of it in our Poisonous People talk for the last year. Poul-Henning attended our talk and we wound up talking with him for a few hours afterwards--he's a great guy and we even got our picture taken with him wearing his "no bikesheds" shirt:



From left to right: Ben Collins-Sussman, Poul-Henning Kamp, Warner Losh, and myself. Here's another shot:



Photos by FreeBSDGirl, another cool BSD person we met at the conference.

How to Collect Money for a Dinner With More Than Eight People Without Going Broke

Have you ever found yourself as the (perhaps unwilling) ringleader in a group outing? Did the check for the group somehow wind up in your lap and people are suddenly looking to you for guidance in how much to pay? Was the meal with a bunch of people who ordered wildly varying meals (and, more importantly, drinks)?

Wilfredo Sánchez and myself, as the unofficial "Cruise Directors" of the Apache Software Foundation, have found ourselves in this role year after year (voluntarily), and having done this at multiple conferences, have learned some valuable lessons about collecting money after the fact for a group outing.

Time and time again, I've seen some poor sap stuck in the "check master" role come up way short of the amount of money owed, and out of fear, wind up eating $100 or more of the group's tab. Typically this happens not out of malicious intent, but out of lack of organization and ignorance on the part of the participants. Should you ever find yourself in the role of this poor soul, here are some tips to make sure that the venue gets its money--and your servers get adequately tipped--without going broke yourself.

• Split the bill evenly: Your best bet for saving your sanity is for everyone to pay "Alla Romana", which means that the amount each person pays is the total cost of the evening (meal + tips) divided by the number of attendees. If someone pulls out a calculator and tries to calculate precise tax and tip for their meal, you have my permission to throw rocks at them (or at least stale dinner rolls). One exception for this is if a few patrons drank a lions share of the bar bill, it's completely fair to ask them to pony up a bit more to cover their part.
  
  
• Tip your servers well: If your servers have done a bang-up job of serving your party, tip at least 20%, and make sure you add this into the cost before splitting up the bill. Make doubly sure that the tip isn't already included before slapping another 20% on. But even if the tip is already included, it doesn't mean that you can't tip a little extra if your server went above and beyond the call of duty--remember that it's really hard to serve a large group of people well.
  
  
• Round up: After adding the bill and the tip together, divide by the number of people, and round up, not down. If the bill comes to $17.48 per person, round up to $20. If the bill comes to $21.24 per person, round up to $23, or even $25. Odds are that most people are just going to have Yuppie Food Stamps (twenty-dollar bills), so making any change that's not a multiple of 20 is going to require some effort. After everyone has been paid and tipped, you can attempt to get change and give people a few bucks back. If the remaining amount is less than the number of people in whole dollars, consider just adding it to the tip.
  
  
• Don't mix up your money: Whatever you do, do not start stuffing people's money into your wallet or, even worse, just pull out the contents of your wallet to use as a bank for making change. This is a fine way to make people wonder if you've turned this into a profit-making opportunity for yourself or, more likely, to wind up spending more of you own money than you should. If at all possible, pay your part first, and pay it in smaller bills that you can use to make change. But basically: keep track of the exact amount of money you've collected, and keep that amount visible at all times.
  
  
• Don't mix up your credit: While you can gather all the cash and pay the balance with your credit card, I don't advise this if at all possible--some people might wonder if you're actually paying or if they're collectively paying your bill. I don't care how many miles you get on your credit card, just don't do it.
  
  
• Don't be the loan officer: If you're collecting money, avoid loaning anyone money at all costs. This is one more thing to keep track of, and it's a fine role for someone's other friend to fulfill while you handle collecting for the check.
  
  
• Be careful making change: If the cost per person is $15, don't let people just start throwing twenties at you and then try to figure out who owes what to whom. If possible, start collecting from people who have exact change and then start making change for others who don't have change.
  
  
• Don't fight for the money: You're always going to have one or two people who had nothing but an appetizer and a glass of water and steadfastly refuses to put up a penny more than the menu price of their meal. Fine. Don't argue--they either a cheapskate or they genuinely can't afford to shell out more money. If it's the former, making a big stink is going to make you at least one enemy. If it's the latter, making a big stink can potentially make you many enemies. Basically, there's no way of winning here, so you can use some of the extra cash you came up with when you rounded up (you did round up, didn't you?).
  
  
• Don't play credit card poker: But more importantly than that, don't let individuals start paying with credit cards. Beg them to go to an ATM or to borrow money from the guy next to them, but nothing says "screw you" to a waiter more than a check folder with half a dozen credit cards in it.