Slashdot Mirror
Starting an Open-Source Project?
Tokimasa asks: "I recently thought of an idea for a software project that I want to undertake. I expect it to be mostly a learning experience, but I'm not sure where to begin. I'm familiar with software engineering practices and computer science topics, but I have never started a project on my own. What are the appropriate first steps to starting a new open-source project?"
Start by reading Producing Open Source Software. Setup Trac or use Google Code Project Hosting. Make sure it's something you're really interested in doing and committed to spending a lot of time on it. Other people probably won't volunteer their time if they don't see at least one other person strongly committed to the project.
Bradley Holt
Build a first stable version with 80%+ features intended. Then you can release it as open source. Don't start earlyer. When you release, do count on doing 20% project, website and community management at least. And count in a week or so to get accustomed to sourceforge.
We suffer more in our imagination than in reality. - Seneca
...I strongly advocate starting your own project from scratch, rather than going anywhere near pre-existing code to the degree that you can help it. Do not listen to the brainless lemmings who screech and whine about "duplication of effort." If it's *your* effort that we're talking about, you have every right to tell them to leave you alone.
There are a number of reasons why starting from scratch can be a good idea:-
1) You'll have a codebase which you'll understand, rather than having to try and comprehend someone else's, which is the product of a brain and a range of experience other than your own.
2) You can be sure said codebase works, because you'll have been able to do your own testing, overseen by you.
3) Often earlier implementations of a particular idea will be written in a technically inferior, less stable, less secure way. This is very often the case with the "Linux must at all costs be an imitation of Windows" crowd in particular. The old saying that if you want something done right, to do it yourself, is even more true in the case of FOSS than in most other areas.
4) (This is probably the single most important one) If your project runs on Linux and becomes popular, sooner or later the GNU zealots will come to call. These are people who are very anxious to make sure that you're "giving back to the community," and that you aren't "taking advantage of your suppliers for your own gain." They do this primarily because they seek justification for being able to dominate others. Starting your own codebase means that you will have the right to experience the intense pleasure and satisfaction that may come from demanding that these individuals commit suicide, preferably in the most agonising way possible, at the earliest possible opportunity. If you start your own codebase, you don't owe anyone else anything, and you can tell the zealots that. The detestable, leftist zealotry exhibited by the reciprocity police is one of the strongest arguments against the re-use of open source code in new development projects. If you don't use anyone else's code, you can make sure that you are able to avoid the above...and to me, this reason alone is justification for starting your own projects when you write more or less anything. Even if you're not using anyone else's code, the zealots may well try to pressure you into adopting the GPL if you're using another license. Express to them an earnest desire that they cease to exist, say it loudly and adamantly, and repeat it as many times as is necessary for them to eventually listen and leave you in peace.
Sourceforge has the correct advice: Release Early, Release Often. I still get no feedback but I'm getting plenty of downloads.
It's OK Bender, there's no such thing as 2.
I don't know anything about the SE textbooks, I never read any of them. I just know from experience that if I don't have some sort of specification, be it a polished document or just ideas in my head that I thought long and hard about, I'm going to produce some nice looking code that doesn't do anything useful.
I usually get small portions of it working during steps 1) and 2). These portions are very helpful to my understanding and development of a technical spec, and sometimes even end up as working code in the finished product. They may even be enough to get somebody else interested. But they are not enough to show an idea of the whole project to somebody who isn't reading the specs and the code thoroughly.
The masses are the crack whores of religion.
I am involved in a couple of open source projects (see my sig). My most recent one, LedgerSMB, was a fork from another program and one we are working *hard* to get into shape (please don't hold the existing source code against us!).
However, here is my advice on politics: every organization has politics and open source projects are no exception. Rather than work on eliminating problems, look at using them while mitigating harm:
1) Don't push people to contribute, but be grateful for any worthy assistance. Note the use of the word worthy. Make sure the quality is good before you give commit priv.
2) Understand that whatever structure you decide on having, there will be elements of benevolant dictatorship and community decision making. LedgerSMB is organizationally very community-oriented, but sometimes I feel like I am looked to as a constitutional monarch (not my choice, but I am the only one with a lot of experience in the insanity that is the current codebase). I have noticed the same trends in PostgreSQL and other more mature projects-- just because one is structurally democratic does not mean that someone does not rise to be the leader.
3) Work on getting support from every other related open source project. Some people may contribute toward your code, others may want to collaborate.
If you would like to continue this discussion, you can email me at chris.travers@gmail.com
LedgerSMB: Open source Accounting/ERP