This is a list of books currently on my To Read shelf... literally. I do not suggest or anti-suggest any of them at this time as I haven't read them yet.
Current Efforts:
Blue Parabola, LLC
HubAustin
web2Project
PHP'ers:
Cal Evans
Eli White
Elizabeth Naramore
Joe LeBlanc
Matthew Turland
Matthew Weier O'Phinney
Planet PHP
Tony Bibbs
Business/mISV:
Bob Walsh
Eric Sink
Joel Spolsky
Micah Baldwin
Paul Graham
Past Projects:
CodeSnipers
HOBY
Judicial Watch
mobile FoxNews.com
NRTW
Great Tools I use:
Drupal
GitHub
NetBeans for PHP
phpUnit
Subversion
Zend Framework
This is not the home of dotProject or web2project. It is the home of CaseySoftware, LLC. Any dotProject support questions should be referred to their support forums.
Since 2001 or so (according to SourceForge) when I got involved in Open Source, I've joined a handful of projects and had roles varying from a general advisor/reviewer to Core Developer to Newbie Wrangler. Yes, that last one was an actual title. But the interesting thing is that I've never started an Open Source Project myself. I've worked with projects that were established, already had communities (some quite small), and already had some structure in place. Recently, a number of opportunities have come to light and one of the interesting ones - but not the most interesting one - involves preparing a small application for release as Open Source... so I find myself considering and evaluating what it would take.
First, I'm a firm believer in that it must be useful now. As great as SourceForge is, I'm not willing to add yet another project that has a grand vision that doesn't do anything. That said, it doesn't need to be perfect. I don't think the application needs to do everything and fully encompass the entire vision in the first release... but it needs to do something useful immediately.
Second, I believe the project has to have somewhere to go. If the first release covers the entire roadmap, it's a development success, but doesn't seem like a good Open Source candidate. In this case, having active users will help you define what the next steps are (and potentially do them), but you may still want to have ideas to seed the discussion.
Next, the code needs to have a certain level of quality. Sometimes I cringe when I look at code I wrote years ago or under a tight deadline or worse yet when both are applicable. I'm never quite sure what I'm going to get and I can't help but think "well, that was dumb!" So what level of quality is required? Not a clue... but it can't be embarassing. That will vary from person to person. I'd also check for some basic security, etc here. If it's compromised moments after release, this sounds like more of a liability as opposed to a project.
Finally, I think some company's cast off project is a bad idea. I don't know how many times I've heard about a company losing market share, considering killing a failing product line, and what's the answer? Open Source it! Bzzt. Wrong. If your customers don't want it, odds are that the community doesn't want it. Yes, most likely some of your customers will want the code to customize and expand upon, but they're going to pursue their goals, not necessarily yours...
What do you think? What are your critieria for starting or joining an Open Source Project?
One counter example
It would be hard to disagree with your first rule. The last thing the world needs is one more partially complete proof of concept on source forge. Two and three I am more ambivalent about.
One clear counter example to your cast off rule though is Firefox. Proprietary cast offs can work, but Netscape did a lot more than fling its collective hands in the air and say "OK we give up, but here is the source" and did not see an immediate avalanche of support.
Eclipse might also fall into the same category.
Sourceforge...
where Open Source Projects go to die. ;) That's one of the things that drives me nuts about SourceForge in general. There's so much crap that it can be hard to find the useful bits.
I think having somewhere to go can be key to building the community aspects. Sure, if it's "complete" you might get a lot of downloads, but you're unlikely to get much involvement, etc from others.
I'm not sure how to get around the code quality aspects... sure, releasing crap can give you *lots* of room to grow, but it's likely to be a liability in the meantime.
As for #1, I think a
As for #1, I think a contributor to the problem is that some people get on there with absolutely no intention of ever writing code. They're hoping that some brilliant, motivated programmer will jump on it and suddenly they'll get the software they want.
But yes, someone should at least be able to do something with your code right away (if possibly after a little tweaking).
I would also add "use meaningful version labels" as a rule. I've seen a lot of projects out there that are something like "version 0.7 stable." I guess that could mean 70% of the features you think the project should have are included. However, if you're "stable" and people are using it, the "0.7" bit is almost entirely ambiguous. Start with Version 1 and rate the stability: alpha, beta, release candidate, stable, mature.
Post new comment