I came across these rules on Greg Beavers Blog. I wanted to comment and add to them (Greg’s rules are in bold.)

1. If you must criticize, criticize with a gentle and humble tone.

Remember open source projects are often done on a voluntary basis. Criticism is tough to take when you’re doing a project of this nature. The problem is, doing a project of this nature, often involves criticism. Probably one of the best pieces of advice I ever received is when you criticize, soften the blow with something positive. Good advice. So when you have to tell a project worker that his code breaks a critical function, remind him/her how good their commenting is.

2. Unless the evidence suggests otherwise, assume that users you don’t know are not interested in committing to the project.

I would have to say this: With regards to open source software, if you’re not 100% committed to the project in the first place, don’t bother. The vast majority of open source software is done out of love for either the initiative or for the love of coding. It’s like being a teacher in the United States: you don’t do it for the money, you do it because you love to teach. It’s like you HAVE to do it.

3. Despite the evidence, it’s probably your fault

Why? Is this like the retail adage “the customer is always right”? But I do understand where he’s going with this. You create a project for a group of people. Each person in the target group complains about the functionality of one aspect of the project. If every audience member complains about the same feature, that’s more than likely not their lack of expertise in the field of software but their expertise in what they want. If that’s the case, you need to accept that you must make change.

4. Follow the rules you apply to those with lower karma!

If you set rules and boundaries for those underneath you, you should probably follow them yourself. If you tell other people coders on the project to comment their code well, and you do not, that will come back to bite you.

5. Don’t apply new rules casually, and simplify if possible

Very simple. If you want to legislate your project, keep a light touch. Don’t micro-manage. I’m sure most coders get micro-managed at work. The KISS (keep it simple stupid) method works so well in so many instances. And remember so times structure and rules can eventually become hurdles in and of themselves. If you demand all project workers do everything in a very specific way, you might find some of those coders not being able to work to their best potential.


6. Assume everything you ever say will become permanent and don’t say things that will come back to haunt you

Hmmm, this sounds like how to succeed in business. But you know that geeks tend to flame on every chance they get. Run into a crowded Linux expo and yell “vi sucks” at the top of your lungs, run to a higher vantage point, and watch the battle unfold.


7. People like to improve their code, and like coding standards

But which standards? Therein lies the rub. Do you create your own standards. Are we talking about open standards? Word format vs. Open Format? Or are we simply talking about how you comment and lay out your code? A lot of the open source programmers I know are absolutely anal about their code. To them, it’s an art. Do you, as project leader, demand all your programmers look at their code in such a way? Are you going to be able to deal with it when one of your programmers does not?

8. Assume there will be politics, and plan for them

And when you’re working on an open source project the politics become even more complex. Remember, you are facing an up hill battle a lot of the time. Drivers. Corporate types who think free work is bad work. Inability to drum up interest in your project. On top of those issues, you have your every day work issues and project management issues.

9. You have two audiences: developers and users

I would say there are more than two. Backers? Sponsors? But which audience is the most important? And who exactly is the project for? Is this an end-user project? Or is this a project that will be dealt with only by other developers? That is going to play an important role. But then you throw in the possibility of financial backers and your audience becomes far more complex. Here’s what each audience wants:

Developers: They want cool, fun code. They want bragging rights. They want elegant code that compiles and does what’s expected.

End-users: They want their program to work. They want to click a button and magic to happen. And they want this to happen without having to A) learn something difficult B) restart their computer every 15 minutes.

Backers/Sponsors: They want the project to happen with a minimal amount of funding. And they want the project to make them money. Tough sell on the open source front. Your best approach: the software you are creating will SAVE them money.

10. Dream big, baby. Plan for the future

Good advice on any front. And make sure when you’re planning your project, if the project is big enough, plan on doing revisions and updates. So many open source projects start off, create a great product, release the great product, and then go away. I’ve used products like this. One of my favorite word processing programs came and went so fast I didn’t even get a chance to miss it. And then there was the Agenda Linux-based PDA that allowed me to serve up a tiny mobil website. Remember, thousands of projects are dead before they begin…don’t let your open source project die a premature death.


Do you have any golden rules for open source projects? What are they?