24
Jump start – when should you go public with your project
No comments · Posted by patrick.c in Talk posts
This blog post deals with the problem of finding the right point in time to go public with your project. When should you write the first announcements, when and how to ask for help… When should you go public with your idea for a project? The sooner you go public, the sooner you’ll get people involved to help you. At least this is what you might think.
As early as possible?
The problem with going public early is, that without any working code it’s not very likely that you attract new developers. There are so many open source projects and you have to show that your project is worth of getting help. The odds of attracting people before you have something to show are small. There is a little bit of a chicken and egg situation. You just have to put some effort into the project before you can ask other people to help. The trade-off is not easy. If you can, then try to get working code out. This has several advantages. As I have stated in my first talk blog post it’s easier to let facts do the talking. According to the 80/20 rule, even when you have written something that works, you’ll still need 80% of the time for the remaining 20% of functionality. ;-) In short: Don’t be too early with your announcements. Better try to contact potential fellow campaigners directly or with small requests in forums etc.
Power of the first announcement
You shouldn’t underestimate the power of the first announcement. If you do it right, then you can get a lot of attention with a well put news article. If you waste this situation with a simple announcement that simply states what you want to do in the future a lot of people might monitor your project for some time, but will loose interest soon. The most people will have forgot your project by the time you have something to show. But depending on the time the first release took, the project name might have a negative connotation, because people think that the project is progressing too slowly. On the other hand when you manage to get out with something that the people can play with, then you’ll have a much better standing. Especially when you manage it to release small updates from time to time. Long story short: Try to keep a constant flow of information and releases after the first announcement or people will think badly about your project.
Conclusion
It’s not an easy decision, when to go public. It’s understandable that you’d like to get help as early as possible, but in most cases you won’t get the desired result and you maybe even get frustrated and stop a promising project. Another advantage is that you’ll end up with less discussions about technologies, internal design etc. if you can show working code. This also speeds up the development, because you can do more coding and less talking.
introduction · starting-phase · talk
