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.
Example of open-source idea that hasn't taken off: the endless work that has been done to create an workflow/information management system.
There have been at least a half-dozen attempts to plan such a system, but AFAIK none have made it to the point of being well-documented, let alone well-coded.
This is a shame, because its one of those "killer apps" that could rocket Linux into mainstream business use.
--
Don't like it? Respond with words, not karma.
They just kept asking, "Where's the source code?"
It really is tricky to get an open source, distributed programming project started, because the new people don't have anything to hack on. There's no jumpstart or catalyst.
I wound up just writing the whole thing myself, and never got around to opening the source. It's a loss, because it'd be much better and much more widely used had the idealistic methodology actually worked.
Got Rhinos?
I think most projects need a powerful leader to get them started quickly and push them in direction. Design by committee is slow. So start with a powerful leader, like a 8th or 9th level Paladin or Wizard to lead your party to success.
-- Sherman Boyd www.twocell.com www.shermanboyd.com
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.
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.
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!
This is one thing I have kind of always wondered about myself. Here's the thing. When a software company (e.g. Microsoft) starts coding a new app, it actually begins several months (if not a year or two) before the idea gets off paper and into the hands of the developers.
Guidelines need to be set, studied and altered to better fit a model. Flowcharts, maybe... what about general funding? Start any kind of project, where you could look at 2 years of full-time development, is going to require some kind of revenue stream. Do you think Windows XP was released after 8 months of coding? Sure, it SEEMS like it was, but sometime back in 1997 Microsoft had the idea to merge Windows 95 and Windows NT. It took them nearly 5 years to accomplish this.
This similar thing can be said for lots of different software. Development doesn't occur overnight. The first draft isn't the BEST draft... there will always be bug fixes and feature additions. In fact, you may start coding an application and half way down the road realize it would be better done some other way and would need to rewrite half of everything you've done. This is something you need to be willing to do from the start of the project.
I know /. is not fond of the folks in Redmond, but M$ has been developing a leaderless team model over the past six years that may be worth taking a look at. Microsoft Solutions Framework (MSF) has a team model that gives each member a key responsibility and holds them accountable for it, but there's no one boss of the whole deal. You can read about it in this Word document.
/. etc and asked for volunteers for the six key positions in the model? If they couldn't get enough takers, maybe the idea isn't so hot. When they get enough, that team would become the nucleus to get the first rev out. After that, the normal OSS process could take over.
What if the person who had a new project idea advertised it in newsgroups and
Try this experiment: get together with someone else, sit down at the same computer, and try to write a piece of software together. Try to write an essay together. Try to fill out a spreadsheet together.
I've been on plenty of committees. The good ones realize that a meeting is to review progress and make sure everyone is clear on the plan. The bad ones think that the meeting itself is the productive work (instead of overhead to get work done).
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 was recently looking around for something like this, and as I remember the most interesting looking project I found was the Open For Business project. They are definatley further along than just design and have at least some code (some parts of the project further along than others). Actually Workflow is but one part of the project, they have a whole range of related things.
The project is based on J2EE standards as well as standards proposed by OMG (Object Managemnet Group). The workflow piece in particular is based on stuff from WfMC.
So, have a look through that. A simple search on "Workflow" revealed many other projects on Sourceforge, otheres look like they might have a great deal of substance as well.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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