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?"
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?
ESR's timeline predictions are pretty far out of whack, so I'm not sure I'd trust his ideas on project management....
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
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).
Another notable quote... "If something is worth doing, it's worth doing poorly". I don't know who said that.
I modded the Troll Investigation and I got