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.
If the project is too big to start with a 1-man code base, at least make a flow chart describing the basics of what the software should do. That is certainly within the scope of a one or two-person effort, and will give the project the needed focus.
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 first must confess that I don't understand what the Bazaar model consists of, but I think it sounds like something akin to 'anarchy'.
Personally, I don't see a project getting off the ground this way, at least not with any semblance of a coherant project.
I also lead an Open-Source project (shameless plug: jspShop) but we are definately proceeding in a structured manner. Perhaps this is some kind of outdated model that is staying around from corporate example, but I can't really think what else we could do. In society at large, even, we have 'leaders' to guide our development.
I don't see it as a bad thing.. I think without some top-level guidance a project would, at best, lose efficiency. I wish I could remember who it was that said this in a previous slashdot post, but I can't. I'll paraphrase it here:
'Tell me what gets things done faster.. talking about implementing ideas, or implementing them'
(I think it was the AtheOS guy? Can't remember).
Anyways, the long and the short of it is.. I think top-level guidance leads to an efficient product with specific goals met. Sure it might aggrevate some people.. but they are free to take the source and turn it into what they want as well. (Ala phpNuke - PostNuke).
It doesn't work. You MUST have some real code before you go open source. Look up the freedows project on google to see a classic example of a
project that failed at the bazaar mode off the bat. I think people want code to play with to get them motivated, not some open source planning committee.
Someone has to make the final decisions. I'll probably get roasted for this example, but here goes.
Look at the discussion & infighting through the recent Linux kernel changes, especially over VM implementations. Now imagine if there was no Linus or Alan to put forth a final decision.
Discussion, debate and arguing are vital, but if you don't have someone (or a very small, focused group) to take that input and render a decision, no progress will be made. Decisions by committee are slow and may not be beneficial to the good of the project.
My memory may be failing me, but it seems like KDE became a bazaar style project pretty early on. And of course, there's Debian.
It seems to me that the most successful bazaar projects are very broad in scope and accompany a lot of small, almost atomic elements that are combined. A single monolithic project that requires huge amounts of coordination for each component possibly requires a strong leader to keep things under control.
Part of this has nothing to do with "cathedral vs. bazaar" anyways. It comes down to convincing other people to get things done, and setting a good example by getting things done yourself. A good manager knows when to debate the architecture, when it's time to start coding, and how to get people started too!
I think getting an open source project going is similar to organizing anything. In past projects, software and otherwise, I've tried two bad methods.
The first was to get a core of an idea and then hunt down people interested in helping. The problem with this is that the people you will attract will not be so interested in getting work done. At best you'll get a lot of armchair coders that are most interested in shaping the idea, often in directions you completely disagree with.
The second was to do it all by myself and hope others will be inspired and jump in. They won't.
What you need to do is put yourself in the shoes of your potential fellow coders. What will get them excited enough to put time into the project? The best example I've seen is GIMP. They got a framework up and working in a short time and made the project modular and extensible. They then primed the pump by getting some cool modules written. Quickly others made modules and next thing you knew there was a large group of developers making plug-ins and actively improving the architecture to make their plug-ins work better.
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.
I think you'd need to adapt this. If you create an iterative process where release dates dictate the last go for a given design release (which hence is implemented while other parties can continue working on the next phase of the design if they choose). The problem is that you cant just have sweeping philosophical discussions while no development goes on. You need objectives, milestones and goals. Not to say that you can't have a conversative process for developing even those but there needs to be a point where even if its not perfect, work starts, nail it more in the next iteration.
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
I'll bet you don't believe in Extreme Programming techniques then. (Although I've never tried the pair programming myself)
Still, you can start with very little, version 0.0.0.1 may not need much more than statement of the goals, and just a bit of code. Version 0.0.0.2 might have some of the major internal APIs defined, a sketch of the user interface, and a detail or two in place. Even at this point it is pretty hard for anyone to contribute anything except opinions. About at version 0.0.0.20 you should have the main building blocks defined (in text), the interfaces between them, and dummy code that does not yet do anything, but does exist. That is the first moment people can see where to put their code, and how to write it. There can still be huge undefined areas ( a web interface goes here, a file system there, an intelligent player AI here, some robotics there, and somewhere we need a booster rocket to get off the ground...)
Even if you do not get many people involved in the beginning, optimize your project infrastructure during those early moments, make everything available and visible, cultivate relationships with the most promising participants, and gain their respect by showing some enlightened leadership. Listen to reasonable suggestions, but cut through with decisions.
Still, expect to do a lot of the work yourself, that's why it is *your* open source project. Linus may claim to take credit for lots of other people's work, but I bet he still works a lot on the kernel. It will take years of time, a great idea, and a great amount of respect and skill and hard work to get there.
Best of luck, anyway!
In Murphy We Turst