Slashdot Mirror


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

8 of 109 comments (clear)

  1. tip by nano-second · · Score: 5, Insightful
    I forget where i read this, but I thought it summed things up nicely.

    "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.
    1. Re:tip by SirWhoopass · · Score: 5, Insightful
      Exactly. This isn't only true of starting a software project, but of most things in life. Some once said, "nothing gets done by committee".


      Successful projects always start out with someone (or occasionally a few people) doing a bunch of work. General George Patton once said, "It's better to have a bad plan now than a perfect plan tomorrow." Someone has to go ahead and start doing some work. Make it available, be open to accepting help. Do not, however, wait for some magic moment for everything to be perfect and have dozens of people ready to go. That moment won't ever happen.

  2. Data Point by FFFish · · Score: 5, Informative

    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.
  3. My Experience by zpengo · · Score: 5, Interesting
    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.

    --


    Got Rhinos?
  4. OpenSource != leaderless. by nairnr · · Score: 5, Insightful

    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.

  5. it's all about the popularity by Bistromat · · Score: 5, Insightful

    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.

  6. Peer teams as a model? by gentlewizard · · Score: 5, Interesting

    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.

  7. Realize that Open Source is a myth by alexhmit01 · · Score: 5, Insightful

    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