Just before 4 PM on Thursday the 30th of May, Sun’s Glynn Foster sent out the first project proposal containing details – sparse though they may have been – of what was being called Project Indiana. The basic outline called for a branded binary distribution of OpenSolaris to be released on a 6 month time timeframe. 35 minutes later, the first response rolled in, and it was not – to put it kindly – enthusiastic.
Without exploring all of the details of Project Indiana, because many are not yet available and this is still largely in the discussion stage , what follows are some of the questions we’re getting vis a vis the effort.
Q: Before we begin, anything to disclose?
A: Sun is a RedMonk customer, and I know many of the folks involved on both sides of the Project Indiana debate personally. Several vendors with interests that compete with OpenSolaris and Solaris – such as IBM and Microsoft – are also RedMonk customers. That might be it.
Q: How long do you think the ideas behind Indiana have been floating around?
A: A very long time. While many will point to the hiring of Ian Murdock as the primary motivation behind the project (indeed, its critics have taken to calling the project Ian-diana in some quarters), the underlying use cases the project is aimed at are well known and understood. I’ve been speaking, as an example, with Solaris engineers for years about issues with the user experience, and it’s some of these same issues that are poised to be addressed by Indiana.
Q: What are the main objections to the project?
A: They vary. The initial criticism of the project focused on procedural flaws in the way the project was announced. Subsequent attacks have centered on a sensitivity to Sun’s role in this project, the potential competition this represents to existing distributions, questions of OpenSolaris/Solaris branding, the need or lackthereof for a reference distribution, or the fact that the project is starting with intentions rather than existing code.
Q: Are the criticisms valid?
A: Some are, most certainly. Take the procedural issues as an example. As far as I can tell, and I’m no expert on the new constitution, the project announcement didn’t follow the actual letter of the law. But the question, as Matthew asks, is whether or not the governance structure is becoming the ends rather than the means.
Q: Is it?
A: It’s too early, I think, to say. But the divisions here, and the emotions behind them, are fairly deep seated. Take the responses, as an example, to Matthew’s piece or Ian’s which linked to it that angrily decry a perceived slight to the OpenSolaris community. I cannot and will not speak for either of those folks, but I didn’t read either as saying there is no OpenSolaris community – quite the opposite, in fact. But the reaction persists, largely because of the divide I’ve previously categorized as new school versus old school.
Q: Is that divide unique to the OpenSolaris/Solaris community?
A: Hardly. Virtually every sizable open source community that experiences change – as the OpenSolaris community most certainly is – will see a similar fracturing of their userbase. This is natural, and to be expected. It will be interesting, in fact, to see how the OpenSolaris community responds to the challenge. Can they unite, and compromise, or will the individual factions dig in their heels?
Q: This is, then, a natural consequence of democracy within open source projects at work?
A: To some degree. The difficulties in persuading a diverse and differentiated community to pull in the same direction are one reason many open source projects (e.g. Ubuntu) choose to follow instead a “benevolent” dictatorship model, where the final call ultimately is up to an individual rather than a group. Democracy can be unwieldy, as the founding fathers here in the US understood all too well.
Q: How about the criticism that there’s no code? Isn’t one of the best practices of open source to start with code rather than ideas?
A: It is indeed a best practice to start with code. We actually strongly discouraged one of our clients from making an announcement at OSCON last year for precisely that reason: they had no code to offer. But I think that in this case a.) time is a factor, and b.) community input will be needed before code is dropped.
Although many within the OpenSolaris community take a dim view of Linux and its capabilities, users and developers have not. Linux is a already a volume play and picking up speed every day (the new Fedora Revisor bits are very interesting), and while OpenSolaris/Solaris have stopped the bleeding in many areas by means of a featureset not currently available in Linux, it’s important that the OpenSolaris ecosystem ramp up a level. That means a different type of Solaris than has been delivered in the past. One that’s easy to get up and running, that allows you to effectively manage and install applications, and most importantly is friendlier to folks from non-Solaris backgrounds. That’s the time element.
On the community front, I tend to be leery of projects that are developed strictly internally and then opened up subsequently. Obviously it can work – and is in fact how Solaris itself evolved – but as we’ve seen with projects like Compiz or Xgl the closed==>open transition can cause significant problems. Some of the governance and contribution issues still affecting Solaris, in fact, are attributable to this model.
So yes, in a perfect world, this effort starts with code. But I don’t see that expectation as realistic in this particular case. I think it’s best to proceed along community lines while incorporating the already running efforts to address some of the targeted problems.
Q: What about the question of branding? Isn’t it possible – even likely – that a binary distribution called “OpenSolaris” is advantaged over other competitors?
A: This is perhaps the most difficult concern to address, because there really isn’t a simple answer. Is it possible that OpenSolaris will enjoy unfair support, via the brand, over Nexenta et al? Absolutely. Likely? Maybe, maybe not. Depends on how well the other distributions differentiate, innovate and so on.
But here’s the question I think you have to ask yourself: is it acceptable that a user unfamiliar to the OpenSolaris/Solaris ecosystem visit opensolaris.org and not be able to build the codebase (easily)? Or that they’d have to pick between a variety of community distributions that they may be unfamiliar with?
In my view, the answer to that is no. Therefore, I think that an OpenSolaris branded binary distribution is in fact a necessity – in spite of the risks. Reasonable minds may disagree, of course.
Some may point out that Linux, in fact, is typically built via distributions as opposed to kernel.org – which is very legitimate pushback. But I think that obscures the reality that the Linux distributions today – particularly the leading commercial iterations – are far more established than their Solaris counterparts. No disrespect intended to the latter, they’re merely not as far along the project maturity path.
Q: I take it, then, that you’re positively disposed to what is currently known about Project Indiana?
A: I am. My view on it fairly simple: I believe Indiana will encourage change, and further that (some) change is necessary to achieve volume penetration. It’s not that Solaris needs to or should become Linux or abandon its current user base, quite the contrary. But there are issues with Solaris, particularly from an accessibility perspective, that should have – IMO – been fixed years ago.
Indiana’s an opportunity to do that, drawing on ongoing work to make Solaris easier to user as well the best practices of successful projects like Ubuntu, in order to bring Solaris to brand new markets. Some of the proposed changes might occur in the absence of a project of this focus, but many would not and have not.
Change can be scary, and most certainly is not always for the better, but I think Indiana is precisely the kind of change that’s needed to make OpenSolaris an option where it’s not today.
What say you? What questions didn’t I answer?
