Interesting debate between Joel Spolsky and web standard advocates (read, for example, Sam’s reply). This reminded me of a question that Mitch Baker asked on her blog about “standards and interoperability” that I had in my to-do list to answer.

Joel’s main point is that the “idealist road” on standards is a myth and that people will just see it as a bug, complain and downgrade (or switch to something else). He’s referring to the decision of the IE team to default IE8 rendering mode to “standard”, which will break many IE-specific functions that people did in the past to make web sites work with IE6 and IE7.

He explains the problem of interoperability in a “many to many” situation (many independent producers and many independent consumers) and concludes (my words) that decentralized environments plus entropy result in a mess and there is nothing you can do about it. You have to learn to deal with it.

And that is something I agree with.

Call it like you want (”browser wars”, “ontology harmonization”, “schema alignment”, etc) they are all various facets of the same problem: contract maintenance in a decentralized interoperability scenario.

To allow independent parties to work in parallel and without central control, you have to “separate their concerns” and you can’t do that if you don’t create/specify a “contract” between them that defines the way in which they need to interact.

Joel rightly explains that such “contracts” (a.k.a. “standards”) are inherently poor or incomplete in describing the bridge between two different concern islands.

The situation is bad enough when concerns and contracts are fixed in time, but it gets insanely complicated when such concerns and contracts need to be adjusted over time. “separation of concerns in motion”, we could call it.

The problem is a nasty one: because the “many to many” environment is completely decentralized, nobody has enough power to replace all three parts of the equation at the same time (consumer, producer and standard). This is, most of the time, a feature, allowing nobody to have enough control to tilt the power more on one side than the other.

But when the standard needs to evolve, even just slightly, you can’t do it without work on both sides.

This always reminds me of something that Ben told me years ago: you can’t craft lenses (thus polish glass) with a single abrasive powder, you need at least two different ones. Why? because no matter how fine and well operating, a single abrasive has specific properties and will create specific patterns on the surface. You won’t see the patterns but the result will be not perfectly smooth. Two different ones will likely remove each other patterns. The more different abrasives you use, the smoother the surface will become.

Which is why both email and the web are such an incredibly messy yet magnificently interoperable systems: their standards are constantly under the action of many different abrasive agents (on both sides of the production/consumption barrier), each one using the surface of interaction with the rest and therefore polishing it by usage/friction.

The result is incredibly polished (where for “polish” I mean “able to allow a huge variety of players on both the producer and consumer side of the interoperability equation”), but also incredibly inertial.

But here is where I think Joel’s analysis gets poor: he doesn’t consider the effect of feedback in the system.

Everybody that tried to build automatic controls knows very well that you can’t design a stable system without some sort of feedback. For interoperability systems, friction is the feedback (where for friction I mean “some interoperability breakdown that has overall negative impact on the system”).

Usage of the contact area between producers and consumers creates patterns, some good some bad. The bad ones cause friction to develop on that surface, both parties natural tendency is to change things to reduce such friction.

Note that this does not mean that the surface will ever be polished, but that there is a natural tendency to follow the “gradient of friction”. Also note how there is no coordination between the various players, so both sides will independently try to reduce friction, not necessarily resulting in a overall positive action.

Joel’s main point is that it’s better to look for a local minimum of that friction gradient, while his detractors are saying that it’s tolerable to “climb up” the friction gradient if getting out of this valley will result in a finding a lower minimum later.

Both sides are are just expressing their subjective views about the world and about their natural search algorithm in a complicated solution space: the first one could be called pragmatic and the second idealist; the first is always guarantee to find a local minimum, but it’s not guaranteed to obtain the best possible one, the second could achieve much better results but might take a long time to find it and sustain a higher level of friction in the meanwhile.

In a search space that is so complicated and has so many players, it is almost guaranteed that using a local optimization process for friction will not yield any long-term dramatic improvements. Joel justifies this saying that even in another (lower) friction minimum, there will still be friction anyway, so why bother.

The other camp doesn’t say that friction will go away, but that braver explorations of the solution space (ones that might actually *increase* friction in the short term) might lead to lower minima later.

Who is right? Which search algorithm do you subscribe to? Which one is optimal? And for whom? For the producers or for the consumers?

There are no objective answers for these questions (each individual had very specific ways they use to ‘explore’ solution spaces in search for an optimal one, it’s probably part of how they perceive the world), but there are things that one can extract from such a debate that are generally useful:

1. immovable standards fail to adapt to the friction feedback loop and therefore die and get replaced. In order for a standard to survive in a stable the system, it needs to continue to change. This is *very* counterintuitive, especially for the kind of people that enjoy working on standards. This disconnect between the mentality of the people that work on standards and its need to be easily evolved in order to survive is a constant source of trouble (see XHTML vs. HTML5, XSLT vs. CSS, WS-* vs. REST, just to name a few);
2. standards, themselves, don’t reduce any interoperability friction whatsoever: it’s the usage ecosystem they catalyze that ultimately polishes the contact surfaces and thus reduces the friction. Again, people that enjoy working on standards have a really hard time understanding this, mostly because they focus on improving the surface polish other than improve its catalytic factor (of which, normally, they know nothing and just stumble upon).
3. standards (and their maintenance efforts) should be judged for their ability to catalyze stable polishing activities around the contact surface rather than for the qualities of the surface they were meant to describe. A good polishing process with a rough surface will always end up more polished that a well polished surface with a poor polishing process around it. This is where claiming that Postel’s principle often leads to deployment problems feels like the fool that when pointed to the stars looks at the finger.
4. successful standards have a ‘good enough’ description of the interaction surface that first enables the catalysis between the separated concern areas and a ‘good enough’ evolution process that enables developed friction to polish the surface, even when scratches are created by its use from one side or the other. Improving the polish of the interaction surface won’t do any good to the standard if its evolution process is suboptimal.

In short, a standard is a process, not a specification.

Failing to express that makes most of Joel’s points moot, like judging a dancer by looking at a few pictures of her performance.

When I was a kid, I remember learning early on about the importance of knowing not only ‘dry’ facts, but to be able to ‘draw relationships’ between them. Learning, I learned, wasn’t about knowing stuff but knowing what to do with it.

Of course, some memorization of facts and rules have to happen in order for a substrate of reasoning to take place: you can hardly discuss about philosophy or history without knowing what ideas were expressed and what happened; but stopping there is a sort of half-baked ‘trivial pursuit’-like way of learning…  it’s like studying math by learning numbers and not the operations that you can use to relate them.

In fact, while learning numbers is the starting point for learning math (and they are useful and necessary no matter how wide and complete your math knowledge becomes over time), they are hardly the finishing point… and, in fact, they get less and less important as your math skills get more sophisticated.

A ‘web of data’ that is merely a collection of facts and symbols is what I would call a ‘pedantic web’… with as much intelligence, soul and usefulness of a know-it-all jeopardy champion.

Sure, we have to start somewhere and even elementary school teachers know that you can’t teach math operations without a basic knowledge of numbers, but it’s important to keep the focus on the fact that there is a huge difference between knowledge and a dry list of symbols (being them numbers, facts or else).

The real learning/creative process is about learning first and creating connections between such symbols later; and making such connections new symbols.

While some people strongly believe that such symbolic reasoning can be performed mechanically (for example, as one would prove a math theorem), I strongly doubt that and the reason is that such a system does not allow disagreement.

Disagreement is the essence of diversity, which is a necessary condition for a healthy, long-lasting, evolving system. Math is a knowledge realm where disagreement can be ruled out mechanically, but it’s merely moving the disagreement somewhere else, in the ‘interpretation’ of its results when applied.

If not, science results done with math as a tool would never be ‘wrong’, or refinable later on. Math is a ‘model’ of the world, and modeling is not a precise, perfect translation, sort of like maps are never as precise as the world they describe (and, many times, that’s a feature not a bug!). This should be very clear in the minds of those building data and metadata tools, but it’s rarely the case, unfortunately.

Most people, at this stage, are happy enough weaving a web of dull factual data, hoping that it would spark more applications to use it, inspire more data to surface and more usefulness to be added to the web as a global information system.

There is nothing wrong with that, but what’s absolutely not clear (at least to me) is how such a vision allows for the diversity of opinion, modeling, belief systems and cultural diversity that is one of the distinct characters of humanity. And that is surely not going away even with the help of technology.

So, Sun decides to buy MySQL.

Great commentaries about the acquisition can be spotted around already, but there is something I feel it has been missing in the move.

To me, one of MySQL’s biggest achievement is not their codebase or their community management (although impressive), but the invention and consolidation of the “unlock the GPL” business model: others had tried before to mix GPL with a reasonable revenue model (Cygnus comes to mind), but MySQL was the first that actually managed to sound reasonable and solid both to the eyes of the free software and open source world and to the eyes of investors and more traditional CTOs.

In fact, Sun’s new management creed has been basically a carbon-copy of MySQL’s plan: use the GPL as a flag for freedom hugging RMS in one hand, while forcing contributions’ copyrights to be donated to the for-profit entity on the other.

Most individual contributors don’t realize the difference between licensing their code under the GPL or giving their copyright to another entity that licenses that code under the GPL. For them, the result is the same: their patches get in the codebase (so they don’t have to keep patching the code at every new release, which is a massive maintenance cost), their name (and potentially their company’s) is recognized (ego massage is always good, and shines on their google ego search too… which is nowadays worth more than any CV) and their inalienable copy-left rights remain protected.

The difference is that if a thousands contributors each own their own copyright on the patches and all licensed them to you using a particular license GPL, you’re stuck forever with that license, unless you go knocking at every single one of those contributions’ rightful owners (most of which would be small private companies that are now dissolved or bought by other entities and really hard to track down) and convince them or their current managers to sign a waiver or a re-licensing agreement.

Which is precisely the situation where JBoss was for many of their codebases…. next time you hear Mr. Fleury telling you that he undersold, think about what RedHat really bought.

Sun, unlike RedHat, got it: their entire open source strategy is basically the same one that MySQL adopted; the GPL forces them to provide the codebase now and tomorrow under the GPL and this makes RMS and the rest of the open source and free software lovers happy, peaceful and collaborating, but owning the code allows the company to re-relicense the code however they please, for a fee, of course, to anybody that doesn’t like or fears the GPL’s terms.

It’s a really clever scheme: those who like the GPL have what they want for free and with the freedoms they care about, those who don’t get what they want for a fee (including the freedoms they care about… different than the GPL’s).

There is a problem with this, though: nobody knows if it really works.

I bet Sun has been trying to preach this revolutionary new way of ‘milking value’ out of this “age of participation” (as they call it), but they have not proven to their investors and stock owners that it actually works to increase revenue and/or reduce costs and/or increase the stock value (which is what they ultimately care about).

One of the necessary conditions for this scheme to work is that you have to convince people that they are not actually working for you for free, but that they are in fact getting something in return and something that compensates the bad feeling of giving away all rights on your work.

MySQL is one of the few companies that managed to be consistently growing, profitable and maintain a healthy and positive perception with their user and development communities under this “unlock the GPL” model. It’s all but an easy thing to do!

By associating the MySQL brand with their own, not only they will have access to their know-how and experience in managing such dynamics, but will also have a premium story to tell to their investors and stock owners that might end up considering this new management direction to be smart and farsighted and not just a blatant and late open source “me too”-ism.

So, first Sun quietly erases their stock history by changing their stock code-sign (no trace left in the NASDAQ database of the “5$ to 80$ back to 5$” swing that scared away any investor wise enough to click on a 5 years chart); then they buy into MySQL’s “unlock the GPL” business model and paint it all over their crown jewels (including their hardware silicon designs!) and roadblock any previous plan, even at the expense of hurting their existing relationships with other open source institutions. Finally, they acquire the original creators and best executors of the business model to both validate their model and to gain more experience to fix and tune-up their own execution problems.

I suspect that it really didn’t matter that MySQL made databases: I really don’t buy into the idea of owning a chunk of the open source stack of so many web sites gives you that much competitive advantage (other than market and PR buzz)… I think that framing the acquisition in terms of validation of Sun’s new business model dynamics makes much more sense.

Whether or not it will be worth the 800M$ cash they paid for it, it’s another story entirely.