That differing opinions can be found amongst differing community with respective to ABI and the willingness to break it is, of course, entirely unsurprising. Much like other architectural decisions, such as security, it involves a series of trade-offs, trade-offs which are as acceptable to one party as they are unacceptable to another.
A cavalier attitude towards ABI means, among other things, freedom to innovate. Strict backwards compatibility, on the other hand, is generally preferred by communities or vendors depending on consistent interfaces.
Ultimately, both factions sit well inside the extremes; no one can absolutely preserve indefinitely ABI forever, as this would require correctly anticipating all future usage in the initial stages of development. Nor are any communities of size that I’m aware of willing to sacrifice compatibility on a whim.
But even within the confines of those less polarizing positions, room exists for vastly differing perspectives. Witness the philosophical differences between GNOME and KDE. Here’s how Ubuntu’s Mark Shuttleworth described them in an interview with derStandar.at’s Andreas Proschofsky:
I think GNOME really set the pace about good guidance, good release management and good stability for downstream developers. And that’s very valuable, that’s one of the reasons why we picked GNOME as the first desktop supported in the Ubuntu platform, that’s probably also the reason why the majority of companies that develop for Linux use GNOME. But it’s equally important to have a very clearly articulated strategy for how to we will introduce waves of innovation. And I think the KDE-guys have a point when they say, if all you do is have an everlasting commitment to a stable API/ABI and do releases once every six months, you can never make big shifts of innovation.
Perhaps you agree with his characterization, perhaps not. But certainly GNOME has had the reputation – deserved or not – for a rigid attention to ABI for years now, and just as certainly the transition to KDE 4 has been less than seamless, for users and platforms.
The implications of GNOME’s long standing philosophical stance, however, has recently been questioned. Opinions on the subject, predictably, vary. Widely.
The basic question facing GNOME is whether or not sacrifices in ABI compatibility need to be made to permit the innovation sought for in a 3.0 release. Leaving that particular question to the community in question – as I very much doubt my opinion on the subject would be either sufficiently informed or of general interest – let’s use it as to ask the broader question: what should a technology’s approach be towards ABI compatibility?
The answer, as far as I’m concerned, is that there isn’t one. Before you cry cop out, however, permit me to explain. When I say that there isn’t one, I don’t mean to imply that there isn’t any answer, merely that there isn’t a single one.
Like licensing, many projects view ABI compatibility as a static architectural decision: you’re for strict compatibility, or you are not. More, that the position taken in the past must needs dictate the position in both present and future. But while this type of consistency has its own benefits – developers, ISVs, and so on know (somewhat) what they can expect – it also has its limitations. Static architectural stances do not, as an example, give projects much latitude in handling the vagaries of dynamic market conditions. It seems more logical, at least in the abstract, to try and evolve the threshold for ABI compatibility to market conditions.
In fast paced markets that are evolving quickly, as an example, some relaxation of strict backwards compatibility might be permitted. But in areas where the pace of innovation is slower, tighter control over ABI increases the likelihood of supporting development.
Ultimately, the goal must be to maintain a balance that creates the widest possible volume of distribution. Miguel is right to assert that “creating an ISV ecosystem is incredibly hard,” and that ISV ecosystems are more or less necessary to sustainable growth and high volume. For the ISVs, it cannot be questioned that backwards compatibility is in their best interests.
But generally speaking, ISV decisions on platform support are made on the basis of cost versus benefit. At least when the decisions are made absent of emotion. While the cost of their investment in a platform increases with each decision to break ABI, a static platform that evolves more slowly and competes less effectively conversely offers less benefit. Linux, for example, has been far less diligent than Solaris about maintaining its backwards compatibility, and yet while they grumble, ISV support is massive and growth is healthy.
Were I in the shoes of the GNOME developers or any other project looking to decide on whether or not to break my ABI, I would look not at internal architectural debates or even ISV relationships but rather the state of the market in which I competed. A feature competitive project would mean tighter attention to compatibility, while a lagging project would mean upping the tolerance for breakage to stimulate innovation.
Either way, I would try and let market conditions dictate my reality rather than an organizational philosophy, adaptability being the key to success in most environments. But perhaps that’s why I’m not running any projects.
