Here’s an interesting bit of trivia. Sawmill reports that the top browser at turbogears.org is… Python urllib 2.4!
6,500 eggs served.
(Of course, the 600MB used for serving up all of those eggs is nothing compared to the 400GB used for serving up the quicktime…)
It seems that many open source projects don’t want to put themselves at the magical “1.0″ number until the software is “done”. In my opinion, software is “done” when it reaches its end of life and is being put out to pasture. That’s one of the great things about software: it’s malleable! Software is much more malleable that many other “products”.
One could start a project by declaring “SuperMegaWidget will be called 1.0 once it has found a cheap, renewable, clean energy source”. That may sound outlandish, and it is, but quite a few projects set the bar very high for 1.0.
Maybe this is some new breed of 1.0 that is different from the kind I grew up with in the ’80s. Do you remember Windows 1.0? It was not pretty or useful. It couldn’t even stack windows (they were all tiled). But, it was a starting point and it did what it said on the box.
These days, it seems like everyone coming out with an MP3 player starts it off at 0.1 saying “well, it only plays MP3s… I’ll call it 1.0 once it plays Ogg, MPEG video, protected WM files and can transparently connect to P2P networks to download other songs you might like”. That’s crazy! If you’ve bothered to package up a release at all, clearly you think there’s something cool and useful there. Give it a proper starting point. Call it 1.0.
One might make the argument that, with programming tools and libraries, you can’t just make changes willynilly after 1.0 because people are depending on the stability of the API for their own products. The fact is that after a project becomes useful and has a community, you’re already somewhat locked in to the API you’ve provided. If you’re not prepared to at least document API changes, don’t make a release. Just leave it in Subversion, which makes it really obvious that you’re likely to change anything at a moment’s notice.
1.0 doesn’t mean “changes are no longer allowed” or even that “changes are hard”. It does mean that anything that might break a user’s code should
These requirements are not too onerous. Python and Java have grown this way. They don’t grow quickly, but I think that’s partly in the nature of the tools. Different packages will be able to change at different rates. It’s especially easy to document and assist with backwards incompatible changes if you keep track of them as you implement them.
Languages like Python that offer keyword function/method parameters and duck typing make it even easier to maintain backwards compatibility while providing new features.
For TurboGears, I started it at 0.5 knowing that such a web development package could use some more outside review and validation before the APIs could be thought of “stable”. I also knew, and said that it would quickly reach 1.0. TurboGears parts were all solid and fairly mature, and it was really only the glue that needed some review.
Even I’m somewhat guilty of 1.0-itis. The forthcoming TurboGears 0.8 release could be called 1.0, assuming the requirements on that development status page are met. I knew that the sprint was coming very soon, though, so I decided that we may as well get the sprint results merged in to the final 1.0 release.
So, I say “embrace 1.0!” And then get back to work, because 1.0 is just the beginning.
There’s a rumor that Newsgator is going to buy NetNewsWire. I completely believe this rumor, and I’d imagine that this has been in the works for a while. When Newsgator bought FeedDemon (and Nick Bradbury), it seemed like NetNewsWire would be an obvious choice for them to build out Mac support.
Since I fully believe this rumor, I’ll just say congrats to Brent Simmons now.
The first time I heard the term “sprint” for software, it was in the context of Zope. A ZopeMag article also credits Tres Seaver at Zope with this and talks about how Zope Sprints are run. I decided to write up how I’m planning to handle this Saturday’s TurboGears “Dilly” Sprint in Ann Arbor in hopes that I’d get some useful commentary. This will also provide tips for the people who are coming.
This is the first sprint for a “new” project. However, true to the ideas behind TurboGears, some of the people who are coming have previously worked with TurboGears parts, mostly CherryPy, before. There’s the possibility that one of the project founders will make it… fingers crossed! Everyone has some level of Python experience.
This sprint is only one day (10AM-3PM). I have no illusions that a group of new people, working together for the first time with new tools, are going to produce thousands of lines of code in a short day. I’d like for people to come there, have fun, get some ideas together for the “Dilly” (0.9) release and write some code in that direction. After the day of the sprint, we can pick up the work that was started and finish it up. By making the sprint just one day, I’m sure it was much easier for people to work into their schedules.
As in the Zope sprints, I’m planning that we’ll do pair programming. For the circumstances that I described in the last paragraph, pair programming will be a big help: two heads are often better than one at generating ideas, and people will be able to help each other find the best way to work on something. Beyond pair programming, I’m planning to use a lightweight, XP-based process that I’ve worked with before. The day will be broken into roughly 1 hour iterations, which will give people a chance to check in with the rest of the group, collectively work through any problems and validate solutions that have come up.
I’m planning to create several team logins with commit access to the svn repository so that we can do frequent integration. As long as all of the computers have Python and Subversion installed at the start of the day, we should be able to get going pretty quickly.
Comments from anyone who has run a sprint or attended a sprint would be greatly appreciated…
