Slashdot Mirror
Nurturing Ideas Into Open Source Projects?
"Until recently, I was the leader of the SquirrelMail project. When it started, we released version 0.1 and people started hacking on it. However, when we decided to do a rewrite, we attempted to start over using the bazaar model from the ground up, allowing for group discussions and decisions. We got caught in a years worth of discussion before any code was actually developed (now, however, its development is well under way and flourishing). I've seen this through personal experiece with countless other projects as well.
As I am venturing into this territory once again with a new project, I'm wondering if anyone in the community has had personal experience with this, and can lend advice as to how to avoid endless bickering about trivial issues. Having a code base to release is obviously a key factor, but in this case, that simply isn't possible due to the magnitude of the task at hand. Advice?"
"Beware `we should...', extend a hand to `how do I...'"
The point being that people who do nothing but talk and argue over details are not going to assist in moving forward and worse, are likely to slow things down.
I hope you're not pretending to be evil while secretly being good. That would be dishonest.
I don't think that OpenSource should be equated with leaderless. When you get into big tasks, there still needs to be some sort of orginization with regards to what you want to accomplish. Asking everyone what they would like to see is one thing, trying to implement them all is another. Just because everyone can code, doesn't neccesarily mean that everything needs to go into blessed code. Any Project needs to have some sort of Project Manager.
There are a number of projects I would like to start when I have the time, some of which I would like to develop on SourceForge or whatever. However, I would still like some say as to what features I think fit within the scope or ambition of a project.
One of the major drawbacks (or benefits, depending on how you look at it) to the bazaar model is that its success depends directly on its popularity. If you make a project, let's say ThneedView, that everyone needs, you'll have people clamoring to submit patches for improvement. The drawback to this, of course, is the amazing number of cluebies who have no idea what they're talking about. The signal-to-noise ratio on a popular open-source project is amazing. OTOH, if your program is of interest to you and no one else, nobody's going to help you. Of course, nobody's going to bitch at you and start flame wars for making pivotal decisions on the evolution of your project, either. This is why I like the Linux evolution model (for example), where everyone can contribute, but someone is ultimately responsible for deciding what goes into the project and what gets tossed.
Paid programmers don't necessarily have to have any interest in the program they're producing (though, admittedly, it helps). Therefore, their projects don't depend on their popularity with the community, and everyone involved (generally, PHB's excepted) has a clue. Then again, this model limits the number of minds working on the project, and thus can be detrimental.
I think most projects need a powerful leader to get them started quickly and push them in direction.
This is exactly right. I was expand this idea by saying that the most important thing is to have someone leading by example rather than by direction.
What I mean is that the ideal open source leader should take it upon theirself to make it so the project is completed, regardless of whether other people join the project. This allows people to join and leave the project at their own whims, and yet things will get accomplished because the leader maintains a continual forward push.
Leadership by example is also important because the only person a programmer will listen too (besides a person that pays him money) is one who has done the most work in the project. This is why the best leaders for open source projects are, in my opinion, programmers themselves.
Free Software is a set of principles. There is a concept of rights of the user. You release it open because its the "right thing" to do.
You can't "start and open source project" because there isn't really an open source project.
There are projects. Open Source is a type of licensing.
One of the effects of the licensing is that you may get help. This is terrific. We use open source projects, if we modify the system, we submit patches. That's the benefit of it.
However, all open source projects are run as normal projects. Many of the top (quality of code) projects started as University projects (PostgreSQL, BSD, etc.). Some of them are run by corporations, but if the anti-corporate garbage from Slashdot is an indication of the programmers (I don't believe it is, however), you won't get support because nobody wants to make anybody rich.
The trick is to build a solid foundation. If you get help, terrific. However, you'll have to focus on project management. It's like being a "real" project manager, but since you don't pay your programmers, they aren't going to take orders as well.
If this project is of use to a corporation, see if they will "sponser" the project. Maybe you can make a proposition (show them that this could make them or save them X dollars if completed, so if they can supply Y dollars or programming hours (YX) then you can get the unpleasant part done).
Be creative. However, there is no magic bullet.
Building software is building software. Whatever license you stick on the final product is separate from the process of GETTING the product.
Alex