Nurturing Ideas Into Open Source Projects?

lkehresman asks: "Over the course of the past few years, I have been involved in numerous open source projects and have been discovering the wonderful oddities with this development model. However, I am perplexed as to how one would go about starting a project with the bazaar model, and if it's even possible. Indeed, ESR states, "One can test, debug and improve in bazaar style, but it would be very hard to originate a project in the bazaar mode." Is this true? Can anyone give any personal testimony to projects that have succeeded being built like this from the ground up?"

"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?"

Comments

My Experience

[zpengo]

I attempted to create a new open source Content Management System (CMS) for an online magazine. I set up a source forge project, developed design documents, recruited a whole gang of very talented programmers, and then spent the next two months trying to make something, *anything*, happen.

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.

Re:My Experience

[slaytanic killer]

Reminds me of an analysis I wrote at Kuro5hin. I am just looking at it again and seeing if I still agree with it:

----

Here are some points I've noticed are useful in building a successful free/open projects.

. Don't assume that you will get any help. This sounds antithetical to the whole point of opening up the source. However, there are other points; an end-user contributes a patch.. and then gets competent enough to understand some aspect of the software that she can provide help on the mailing lists. Eventually that person may contribute more. And even if not so many developers help out, you probably at this point have an infrastructure that is good for efficient (== less costly) support. As Netscape learned, opening up the source is not some magical fairy-dust, but it does have some very deep overall advantages.

. Stable mailing lists. Should have an archive, so you're not answering the same question over & over. As well as a faq. You might find that much of this infrastructure is very useful even just for purely internal projects.

. Have a pretty good first release. That's how you attract users. The point is that some of these users start liking the software, and would rather help it along rather than switch to something else that doesn't quite satisfy their needs. A secondary advantage to this is that you'll probably have a good design at this point, since you were forced to deal with the monster. Make your mistakes before releasing it, so the developers will know that you have experience and trust that you understand the sticky corners.

. Feel free to look at other projects. It clearly seems like you're developing in Java, so I'd suggest looking at the guys at jakarta.apache; they have an entirely straightforward approach to things, even if one of the mailing-list archives gets bounced around to different URLs sometimes...

And at this point, you probably will notice that you are doing the best practices that you should have been doing for any project, internal or otherwise. (Making sure to comment, for example.) Just a small generalization to external development. And it will probably be some of the best management training you will ever find.

Organized software development

[isa-kuruption]

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.

Peer teams as a model?

[gentlewizard]

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.

What if the person who had a new project idea advertised it in newsgroups and /. 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.