My Working Theory Of Open Source Project Leadership

After running Cobbler for 4-5+ years, observing countless other OSS projects, and now starting up Ansible, here is my current operating theory of the way Open Source projects should REALLY be run.  I have refined this over the years.

I offer this up in that people can look at it and say “wow, that is not how I run my project” and maybe look at it differently.  For if you are giving away code and NOT reaping the rewards of community contribution, maybe you gave away some code… but what else did you get?  If you’re just developing a project and it happens to be free code, you really should learn to expand your horizons a bit, and you can be surprised at what comes.

I’m long away from my days of drinking the Open Source proverbial Flavor Aid, so this is intended to be extremely practical advice to a project leader.

• Do not create an application.  Create a framework for like-minded people to create an application.   The application matters but if random folks can’t easily contribute to it, you have failed.
• Have all your documentation in line when you launch the application/tool/whatever.   Contributors generally do NOT write documentation, so you may end up spending 50% of your time on docs.   The documentation IS the project.   Anything that is not documented does not exist, so take honor in this.   When something new gets added, document it immediately.
• Consider your audience when writing everything.   Don’t just explain how something works, teach your reader why they should care, and inspire them to use your tool.
• Offer amazing quality support at first, to build an audience.
• Do NOT offer amazing quality support later, to build a community that is self sufficient, or it will consume you.  Cobbler’s self sufficiency improved later when I wasn’t giving everyone answers all of the time.   I hate to sound like Machiavelli or something, but cultivating inavailability is pretty important.   Let issues and concerns sit and they resolve themselves sometime, devote your attention where it can cause the most good.  If you are always there, your community will depend on you, and you do not scale.  Help out when no one else can.   Do the important things.
• Realize that you can’t please everyone.   Aim for pleasing yourself and a lot of other people with similar needs.   It is fine to dominate half of the world, be like Napoleon and don’t try to take Russia.   You know what happened there.   He made a bad quality software product by incorporating too many user requests.
• Always build simple code because your ultimate goal is not to become a developer of a project, but a manager of a project.   Mostly just merging pull requests and having things done before you can think about them is ideal, because, let’s face it, one person doesn’t scale.  Communities DO.   Your goal should be about making things happen, and coding is not the only way to make things happen.
• Leave some tickets for RFEs open for a while.   Folks need to be coaxed into learning to contribute code.   The “Little Red Hen” phenomenon is big in OSS, where users can be taxing — demanding, but sometimes not giving back.   Encourage them to contribute by being an occasionally scarce resource.   You should be doing the big stuff, not the small stuff.
• Deny any features that will become a support burden or cause too many user questions.   User questions are bad for two reasons.  They take your time, and two, they make your product be perceived as to be hard to use.   It is much better to have a small project that just does what you think it does, than a big one, that is a support burden.
• Marketing is something most developers suck at, but it’s more important than you think.  I don’t think Requests is a very interesting Python library, but it’s one of the top followed things on Github because it was marketed very very well.  Also, I would venture many rails products ARE more successful due to the high number of bevels and drop shadows on their web sites.   Bringing contributors to your project is the most important thing, so invest in this.
• Don’t do anything small.   Even if you’re doing something small, have confidence and aim for changing major things.  You don’t know what can actually happen.

Yeah, so I realize that is kind of jaded in places.   Most people don’t see that, but open source projects should be all about how you, as the project leader, can make yourself scale, and give people tools to empower themselves.

I think it’s important to not create end products, but to start avalanches, and empower people to create better things where someone wasn’t previously rallying them and enabling them to create better things.  It’s about bringing people together and then being surprised at what they do, and what you can learn from them.  I get much better reward from working with people than with the software.

Actually, that isn’t very jaded at all.