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?
What part are Universities playing, or have they all resigned themselves to keeping up with MFC and the latest WINAPI?
Are they able to participate in nurturing meaningful Open Source or is it beneath them?
Isn't that a big success of bizarre, um, bazaar thinking?
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
ESR's timeline predictions are pretty far out of whack, so I'm not sure I'd trust his ideas on project management....
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).
I think most open source project's out there, especially the windows clone desktop stuff start like this:
"Hmmm, people really like this great Microsoft/Adobe/Whatever app...hmmm, i know let's try and copy it, sure it won't be nearly as good as the original, but oh well..."
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.
1. get an idea
2. write a program using it
3. repeat
just do it. don't talk about it.
Remember this one thing, committee's can't program, I've noticed a trend that any open source project that starts with over four team members seem to just sit around and talk, and never accomplish anything. All of the successful projects started with one guy doing something because he wanted to, and others helping him along the way.
Discussion is good, but remember, talking design all day doesn't actually build anything.
Our website developed along a bazaar model.
A group of us had been experimenting with news and analysis stuff, on other sites and on a separate website. Then, someone offered a domain he owned for use.
Everything just came together. We had a vague, open idea (a news website with a particular editorial style) and we all loved it so much that we did, piecemeal, the practical work needed to get the thing up.
we found hosting, modified scoop in order to make a closed editorial queue, found an opening cadre of users.
we worked so hard, and made so many compromises, because we were all motivated by a reward -- getting the site up -- and we didn't have too much invested in each little idea individuals had about the site.
if you stop your motion, your dynamic excitement, and try to boringly work out principles, you will get dragged down.
if the nature of the technology you are working with allows it, do NOT stop. discover principles of structure for your idea as you go.
Goat sex free since 2001
What do Slashdotters think about a project to
ban the infamous uber wannabe cyber-journalist-
novelist-philosopher Jon Katz forever (including
all facsimiles) from www.slashdot.org?
Could open source be a new wave in Rapid Application Development
Ie., Many eye's (and hands) approach
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
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.
Oh, it's entirely true. If you weren't in on the ground floor (RMS, Linus, Taco), you don't have that much of a chance of originating a successful Open Source project. I mean, have you browsed at sourceforge lately?
Which brings me to my next point: why open source? If your idea is worth doing, it's worth doing right. Which involves drawing up a business plan, getting funding, and, if you can pull it off, cashing out with an IPO and living the rest of your life on your own tropical island, surrounded by beautiful women. (Okay, to tell you the truth, if you're anything like the typical slashbot the women just aren't going to be happening even with the money; but the island's nice.)
Besides which, we need more innovative tech startups right now to jumpstart the economy. If you look at a chart of new IPOs vs the level of DJIA, the clear trend is that the more IPOs there are, the higher the stock market goes (and therefore, the better the economy is doing). So we NEED more high-tech companies being created and taken public right now. In light of the recent terrorist attacks and their clear purpose of disrupting the American economy, I'd almost say it's your patriotic duty to start a tech-company if at all possible -- the same way it's the duty of every muslim fanatic to travel to Mecca at least once in a lifetime.
Slashdot: Open Source, Closed Minds.
Thank you for the insight, Captain Duh.
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!
Sure you will get bug reports for your program, but it really isn't much different than commercial development (except you don't get paid). About 90% of the patches outsiders submit to you are going to be useless or have to be totally rewritten.
It's maybe not such a good idea to take stuff such as "The Cathedral and the Bazaar" as a description of how software development, free or otherwise, ought to be handled. Here is some good analysis and criticism of "CatB" et al. .
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.
end advice as to how to avoid endless bickering about trivial issues
You sound like you've already had more experience in this area than most.
From what I've seen in the Linux camp, bickering is allowed to continue so long as valid points are being generated. Once the antagonists freeze their positions to merely make themselves look good, then it is time for the project leader to exercise benign dictatorship rights and pick a resolution.
And, as others have noted, participants that provide substance toward a solution are more valuable than participants that talk about solutions, and those that talk about solutions are more valuable than those who just gripe and whine about what's bad without suggesting positive improvements.
Paraphrasing from the money aphorism:
"Provided by the management for your protection."
You might want to take a look at Binary Cloud, and maybe talk to Alex Black, the project's originator. It's in its r2 stage, now, but Alex built most of the r1 version himself. From the homepage: "binarycloud is an opensource, enterprise class web application platform." Mac
Having been involved with its development almost from the get-go, in the good old days when Netscape 4.0 was beating the pants off of Internet Explorer and mostly supporting the standards better than IE, I figured it'd be exciting to be in on the ground floor of something new and visionary.
What I wasn't ready for was the clashing of inflated heads, the war of egos, the cacophony of nonsense. I got in on the ground floor, got involved in some flame wars (don't ask what about, i can't even remember) and got off shortly thereafter. The bloating code and slipping deadlines are a testament to the impotence of Mozilla's development model.
The bazaar's just too bizarre for me: I'll stick with the tried-and-true methodology of project leads, senior and junior developers, thanks.
Easy does it!
This comment has been submitted already, 276865 hours , 59 minutes ago. No need to try again.
Seems to be real helpful as to explaining the value of development talent vs. ideas.
To bad those with good ideas have to deal with coding difficulties created by the
development talent.
[shrug] if only coding was alot easier.....
A project is dead in thw water without "buy in" from project managers, devs, test, etc etc o and yeah, USERS :D
----- Whats wrong with this picture? http://www.revoh.org:1234/whatswrong
but Microsoft likes to take code that is already completed and figure out how to make it better. They take Windows,Word,etc code and start working on improvements.
No one likes to admit it though. It is a perfectly good model to work with, and I am sure ideas get translated into working prototypes before they are submitted...they are probably given the green light much more easily that way.
I have 3656.9 Bogomips. How many Bogomips do you have?
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).
Any application I start, opensource or not, I always seem to go back and redo it a dozen times before it's right.
Am I just a poor coder, or am I not putting enough effort into planning or is this normal?
Lately I've been better about it, but I can go back and look at projects I did 6 months ago and think, "What the heck was I thinking?" and redo it 10x better.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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.
Less pining for ESR rhetoric, more coding!
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
"Bazaar" is a rather distorted view of how open-source projects run. If you try to start one that way, you will get an endless discussion of specs and no code. And if you tried to run an on-going project that way, you'd either get the same endless discussion, or infinite forking and no progess.
Open source projects start with one or two people defining the core and writing some code, then recruiting others to add to the code base. They progress if the founder is good enough at dealing with people to be able to hand out assignments to volunteers and to decide which improvements do or don't get into the code base. That is, they are run as mild dictatorships: Linus Torvalds welcomes suggestions but ultimately decides what becomes part of Linux. Anyone could go make his own changes no matter what Linus thinks, but given the respect Linus has earned, if you fork the code you will probably be working alone. Linux coders voluntarily submit to Linus's decisions because it's better to be working with Linus and 10,000 others than to be going it alone... It's a dictatorship that is benign enough that people volunteer to come under it, and dissenters can safely be ignored rather than shot.
You might want to examine how Larry Wall is
handling perl 6. RFC period, followed by a set
of decisions by Larry. Seems like a good model,
although YMMV.
Well, if you browse sourceforge you'll find plenty of examples of where it hasn't worked to start without code. There must be an example or two where starting without code worked. Perhaps GNOME is an example? At least, I remember Miguel proposing GNOME to Red Hat before there was any code (although if we count various bits of code from midnight commander maybe that's not even an example).
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
This article couldn't have come at a better time. /. community:
Have been having problems along the same lines. Am interested in creating an ERP (Enterprise Resource Planning) system for small/mid sized businesses, based on open source. Basically a Linux/Apache/Tomcat/MySQL server, serving up web pages as needed. Lots of interest from folks that I talk to, but no-one is interested in coding. In the early research phase right now, and am ready to start creating reqts docs (spec to follow). I'd like to do this "the right way" with system design, (small but concise) docs, etc.
My questions to the
- Does such a product/project currently exist?
- Would your company be interested in (seriously )trying such a product?
- How much would they be willing to pay - round about figure: 1K, 10K, 100K, etc. (I realize this depends on # of users, features, etc.)
...that you are supposed to apply the Bazaar mode only AFTER your project is "runnable and testable", according to ESR ( "The Cathedral and the Bazaar" ).
Linus is said to have started from scratch, built something that worked (little, and poorly, but worked), and then thrown it out to a world which just happened to have been waiting for exactly that.
I think that this is the key: give folks something that sort of works, to fire their imagination and get them to commit, and then (assuming that there really are folks who care passionately about getting this hypothetical project working) it'll take off.
If you are proposing the 123rd super-duper-programmer's editor, don't count on folks getting all fired up. The first really usable version of Unix which could run on a PC without sending a month's pay to SCO got a lot of folks really excited.
See what I've been reading.
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
It's also critical to look for input and support in the right places when using the 'bazaar' model. Volunteers don't magically appear out of the ether. Starting out with a discussion and some code on the email list or newsgroup of a related project is going to be much more effective than just setting up a sourceforge site and posting to freshmeat. The Cheetah (www.CheetahTemplate.org) project is a great example of this. Someone posted a 'how do I ...' msg to the webware-discuss mailing list which started a huge thread on Python-based web templating solutions. Cheetah, and several other projects, were spawned by that thread. The webware-discuss list acted as their nursery.
Successful pair programming is based on both people being willing and eager to actually do the work.
Getting a project started by committee sometimes consists of a bunch of people, each of which hopes that the others will do the actual work.
Open source projects, and other projects, that attempt to start in the latter style generally don't get anywhere fast.
"A simple search on "Workflow" revealed many other projects on Sourceforge,"
unfortunately any search on sourceforge reveals a hundred projects that exist in name only. They really ought to do some house clearing.
War is necrophilia.
But you must admit, the number of people wanting to start up "workflow" projects (an inherantly boring topic to many) is probably going to be a lot less than the number of people working on, say a new editor or other development tool.
So, the number of sheer "shell" projects under "workflow" I think is less, but like I said I only examined the one I mentioned at all carefully. Some of the others sounded good - a lot of times I use the number of message posts as an initial determination for alive a project is.
In the general case though, I have to agree with you that Sourceforge could probably use a sweep for projects with no activity ina year and no code at all!
"There is more worth loving than we have strength to love." - Brian Jay Stanley
What boggles my mind are searches for "project mangement" and "intranet". You'd think that people would be better off working on sourceforge itself rather then starting the 500th project management tool. And to be honest most of them suck totaly. In the meantime a comprehensive project management tool like sourceforge is just about impossible to install anywhere.
War is necrophilia.