You may have heard about the recent release of source code of a project called Diaspora. After raising $200,000, the developers spent three and a half months writing 6,500 lines of code. As the developers themselves wrote, We know there are security holes and bugs....
Many people will write many things about Diaspora, but none of them are particularly interesting to me. Instead, the discussion of the Slashdot story Security Concerns Paramount After Early Reviews of Diaspora Code fascinated me—especially the repeated assertion that "this is pre-alpha code".
I don't know what that means, and yet it appears to be conventional wisdom.
Does the software not work? (Apparently not well, if it's full of bugs and security holes.) If not, why release it at all?
Is the software not finished? (What does finished mean, anyway? Abandoned? Superseded by another project? Bug-free? None of these seem to apply.)
Does the project not do everything its stakeholders want it to do? (See also "finished".)
Is the project difficult to install? (If so, why not say that directly?)
Does the project need optimization? (If so, why not say so?)
Does the project not pass its tests? (If so, why release? Does it even have tests?)
Each of these questions reveals one of two underlying assumptions:
- We don't expect the software to work at all.
- We don't expect the software to do everything we want it to do yet.
In the first case, there's little value in making a public release. It's purely a publicity mechanism: here's what $200,000 bought you. We really did write code this summer, we promise. That's all well and good, but that's not very interesting to me, as software that doesn't work at all might as well not exist. (I haven't looked at the Diaspora code, so I have no opinion on its efficacy or quality. That's not the point at all.)
I understand the second case only as a truism. If the world of software development had any serious history of releasing projects which, on their first public release, did everything most users wanted and never had subsequent releases, I might be able to muster up some surprise that not every feature everyone could possibly want is present in this first public release. (Again, I have neither opinion nor comment on how well Diaspora's code meets public expectations.)
In short, "it's pre-alpha code" is a deeply silly comment, as if the speaker were sagaciously stroking a long, flowing beard while imparting the wisdom that there may be more releases in the future which add new and improve existing features.
Such is the way of software development (especially FLOSS development), which shouldn't be much of a surprise to anyone by now.
I keep returning to this theme because "it's pre-alpha software!" is a lazy refrain to often used as an excuse for bad behavior on the part of users as well as developers. Developers too often use it to justify working on lots of features, completing few of them, and throwing a greasy wad of code over the wall which may or may not be useful. Users too often use it to console themselves that buggy, incomplete, late, and half-polished software is worth using anyway or (my pet peeve) that software that doesn't do everything it will eventually do is probably not worth using now, even if it is.
In other words, because many developers can't ship working software reliably, those developers who can probably don't, and we'll argue with them up and down instead of actually testing their assertions. Software is difficult. Let's all eat pie.
I'm not sure there's a solution besides regular releases and a sane scheduling of features. Your project doesn't have to do everything everyone's ever dreamed it might someday do right now, but the features you ship this month really ought to be usable. Forget all of these cutesey linguistic games with the Greek alphabet (adding prefixes because you've run out of letters before α?). Be a grownup. Document what works and let us decide for ourselves if it's worth using.
(Note: version numbers of less than 1.0 are a different rant, one about change management. I'm thinking of you, CPAN authors.)
At least according to Wikipedia, "pre-alpha" is before (system-level) testing. That at least ought to make it questionable, on the basis that if even the developers haven't done any system-level testing, how can you even contemplate that it might be useful to others?
But there is one reason you might want to do this, and it is to get feedback from externals. They certainly now have plenty of that, and now know exactly where to focus development effort. The fact that they spent $200K before knowing this might be a (second) interesting question.
This is not the approach I would take: I'd want to get a few real users more closely involved and get them to give me the feedback I wanted before going public. However, for security issues, that probably isn't viable, as few users (or developers) have these skills. If you really had to know about security issues on day 1, exposing your early code to full inspection and disclosure might be a reasonable step.
I agree!
I understand why Diaspora should develop its code in the open. I don't understand why inventing terms to excuse away releasing code that you don't trust is useful.
What term did they make up? I don't get the title of this post?
Maybe they should have called it Diaspora Star... :-)
lol @dagolden ++
Or Diaspora 1.0 where the .0 means developer preview (*cough*KDE*cough*)
One important difference is that people can actually install and use Rakudo Star. (You're right, though: Rakudo doesn't have a specific version number or an attached Greek letter because none of those indicators encoded sufficiently interesting information.)
I assume that pre-alpha release of Diaspora simply means proof-of-concept prototype, to get feedback if they go in the right direction.