What are the common pitfalls when starting a new open-source project?

Question

The producing open-source software book is a gold mine of information on starting open-source projects. Yet I am hoping to learn more from the experience of stackoverflow users and was wondering what are the mistakes you made when starting a new open-source project (or difficulties you encountered when attempting to contribute to a new project), and how would you avoid these traps to become a successful project*?

*Successful loosely defined as a project that is used, and attracts active contributors.

Answer 1

My two biggest mistakes are:

1. I expect the world to fall in love with my project as soon as I post it anywhere. If I don't get immediate feedback how great I am, I quickly lose interest.

2. When I get quick feedback, I often don't respond on a timely basis because I have so many projects.

Answer 2

The first pitfall is to start a new project when there are already plenty of existing projects that are planning to do the same thing.

Answer 3

Currently I am starting a blog based on a talk that I have given on the FrOSCon here in germany. First article: There shall be light – things to keep in mind when starting a project

Maybe this helps. I don't know how long it will take to write the following 19 blog posts.

I'll answer clinton here:

Not so obvious stuff for new users is:

For User focused software:

• getting started guide (Get the software to run quickly)
• screenshots! Users love screenshots and too few projects provide them

For developer centric software:

• getting started guide ("get to code quickly" for example by explaining dependencies, structure, compile and start process)
• code of conduct

I'll think a little bit more about it and add it here.

Answer 4

"Eat Your Own Dog Food."

Be your first user. This is good:

• to know what you're doing
• to motivate yourself
• to get early feedback

I think it's nearly impossible to write open source software you're not using yourself.

"Eat Your Own Dog Food" tries to break out of the vicious circle: Nobody uses the software because it is not useable; it is not useable because there is no user feedback. Try to develop something that is useful for you and see if it sticks and gains some traction.

Besides using the software yourself “Release Often, Release Early”. With release I do not mean publishing some source zip somewhere but a real end to end release.

Answer 5

Choosing the wrong license (for different values of 'wrong') is a common pitfall. Two examples:

1.) If you're using a license that does not allow for relicensing under different terms and you accept contributors code, you need to keep in mind that the code suddenly is not yours anymore. This is fine for some hobby project, but might limit your commercial options later. Of course, it also limits other's commercial options too.

An example for this is the GPL. Include contributed code under this license and you're bound to the GPL yourself and can't decide to dual-license later (unless you nail this down for every contributor). Even a simple change of the license to a similar OpenSource license is impossible: See the linux kernel - it's bound to GPL V2 and can't be updated to GPL V3.

2.) If you're using a permissive license (e. g. Apache, MIT, BSD) you need to keep in mind that not only you can go commercial and close the code later, but anybody else can do so too.

Don't get me wrong: I like the GPL, I'm happily contributing to GPL projects and am glad that these projects exist. I also like BSD, Apache, MIT (the permissive ones) and am contributing to projects that others exploit commercially, e.g. through "Enterprise Editions" of the software that I'm getting OpenSource. It's all fair game - you just have to be sure what options you want to have later. None is better, they're just different.

Answer 6

Positively super great documentation is a must.