Geek Answers Handbook

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

publishes an open source book - it is a gold mine of information on launching open source projects. However, I hope to learn more about the stackoverflow user experience and wondered what mistakes you made when you started a new open source project (or the difficulties you encountered when trying to contribute to a new project), and how would you avoid will these traps be a successful project *?

** Successfully defined as a project that is being used and attracting active participants. *

+4
source share
6 answers

Choosing the wrong license (for different values ​​is "wrong") is a common mistake. Two examples:

1.) If you use a license that does not allow relicensing under different conditions, and you accept the membership code, you need to keep in mind that the code is suddenly not yours. This is good for some project hobbies, but may limit your sales options later. Of course, this also limits other commercial options.

An example of this is the GPL. Include the provided code in accordance with this license, and you are tied to the GPL yourself and cannot solve the dual license later (unless you nail it for each contributor). Even simply changing the license to a similar OpenSource license is not possible: see Linux Kernel - it is associated with GPL V2 and cannot be upgraded to GPL V3.

2.) If you use a permissive license (for example, Apache, MIT, BSD), you need to keep in mind that you can not only advertise, but also close the code later, but someone else can do it.

Do not get me wrong: I like the GPL, I happily contribute to GPL projects and I am glad that these projects exist. I also like BSD, Apache, MIT (permissive) and I participate in projects that others use commercially, for example. through the "Enterprise Editions" software that I get OpenSource. This is a fair game - you just have to be sure which options you want to have later. No, better, they are just different.

+2
source

Two of my biggest mistakes:

  • I expect the world to love my project as soon as I publish it anywhere. If I do not get immediate feedback on how good I am, I quickly lose interest.

  • When I get feedback, I often don’t respond in a timely manner because I have so many projects.

+8
source

"Eat your dog food."

Be the first user. It's good:

  • to know what you are doing.
  • motivate yourself
  • to get early feedback

I think it's almost impossible to write open source software that you don't use yourself.

"Eat your dog food" is trying to break out of the vicious circle: nobody uses the software because it is not suitable for use; It cannot be used because there is no user feedback. Try to develop something useful for you and see if it sticks and gets some traction.

In addition, you yourself use " Release Release, Release Early ". With the release, I don't mean posting some zip source somewhere, but the real end is to the end.

+3
source

The first mistake is to start a new project when there are already many existing projects that plan to do the same.

+2
source

I am currently starting a blog based on the conversation I gave to FrOSCon here in Germany. First article: when starting a project, there should be light things.

Maybe this helps. I do not know how long it will take to write the next 19 blog posts.

I will answer Clinton here:

Not so obvious material for new users:

For user oriented software:

  • getting started guide (run the program quickly)
  • screenshots! Users love screenshots, and few of them provide

For software-oriented developers:

  • getting started guide (“get code quickly”, for example, explaining dependencies, structure, compilation and startup process).
  • code of conduct

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

+2
source

Positive, excellent documentation is a must.

0
source

More articles:


All Articles