Avalon / Indigo / Mono Q&A

Given Bob’s post here, and the number of times its come up in conversations since the announcement, I thought I’d take a moment to post some thoughts on the recent announcement that Longhorn components Avalon [1] and Indigo will not be made available under the same terms as C# and the CLR, and that those seeking to utilize them would be required to license them directly from Microsoft. The gist of the speculation and commentary I’ve seen is that this announcement will effectively kill the Mono project. Understanding that I am in no way, shape or form speaking for or on behalf of the Mono project, what follows is my outsider’s take on the situation. I’ll also note that I haven’t had the chance to speak with Miguel and team on this, though I hope to soon; either way, I’d recommend you watch the Mono folks for an official response or more detailed insights.

Q: Before we get to the question at hand, does this come as a surprise?
A: While a few people – Bill Higgins in a comment on Bob’s post, for example – have asked how this decision aligns with the previous release of C# and the CLR to ECMA, I’m not particularly surprised at this. The incentive to standardize a language or runtime is clear; developer recruitment. By submitting its creations to ECMA, Microsoft at once made its future language and runtime more viable to audiences outside of its core constituencies. It is, in fact, what made Mono itself possible, although Microsoft without question has mixed views on that particular development. Avalon and Indigo, however, are completely different animals. It’s increasingly clear that both technologies are going to be the means by which Microsoft attempts to differentiate Windows from competitive offerings. Given that, and the fact that Microsoft is clearly uncomfortable with even the basic level of competition that Mono offers, no, I don’t consider the decision a surprise. It certainly doesn’t help their ability to position themselves as open, however.

Q: How do you mean that?
A: Well, Microsoft is actively trying to shed its label as strictly closed source and proprietary, for a variety of reasons involving constituencies from individual developers up to regional and national governments. While they are certainly not trying to recast themselves as open source advocates, they are taking a more constructive approach these days, even going so far as to acknowledge that open source will be around for a while. Despite complaints that its Office Open XML Formats aren’t open enough, they at least offer the possibility of cross-platform application and competitive instantiations. By effectively closing the door on Avalon or Indigo to Mono (because it’s tremendously unlikely the two would be able to reach mutually agreeable license terms), Microsoft is limiting the options for applications developed using these technologies, both in terms of deployment and development. That’s not open, but again, is not a surprise.

Q: So, back to the original question – does this kill Mono?
A: No, I can’t see that at all. It’s not ideal, but is far from the killing blow implied here:

The policy is likely to kill budding interest from the open source community in further extending aspects of the Windows and .NET architectures to Linux and Unix.

Asserting this implies, to me, that the success of Mono is and always has been predicated on the availability of a fancy UI layer/markup and robust messaging layer. I don’t buy that; to me, the promise has always been about making C# skills – and even better, applications – portable across platform in much the same fashion as Java. The folks that I talk to or track that develop in C# didn’t do so counting on the fact that they’d someday be able to develop Avalon applications in XAML, but rather because they enjoyed the productivity and performance of C# compared to available alternatives.

Q: You don’t think losing the ability to clone Avalon and Indigo will deter some developers?
A: I think it depends on what the roadmap holds. If the Mono roadmap fails to come up with a response, an alternative approach, to the stack offered by Longhorn, it’s certainly possible that they lose some developers, yes. But I think it’s far more likely that the Mono folks will be creative and offer developers similar if not identical functionality to what they’d have in Longhorn.

Q: But isn’t Longhorn likely to be a killer application stack?
A: Yes indeed. The combination of technologies in Longhorn – despite the numerous feature cuts – is likely to be quite attractive for end users and ISVs alike. But saying it’s going to be compelling is different from saying that it’s unassailable. Let’s look at the approaches taken towards tackling Avalon and Indigo separately.

• Avalon: In a post from last April, Miguel discussed the possible options with respect to Avalon as follows:
  

  I see two possible options:

  • Implement Avalon/XAML and ship it with Linux (with Mono).
  • Come up with our own, competitive stack.

  I think someone will eventually implement Avalon (with or without the assistance of the Mono team), its just something that developers enjoy doing.

  This announcement would seem to eliminate the first option entirely, at least under the presumably safe assumption that licensing could not be worked out. For those worried that even the second approach may be invalidated by patent concerns, Miguel goes on to say:

  Are there patents in Avalon? It is likely that Microsoft will try to get some patents on it, but so far there are little or no new inventions on Avalon:

  • Canvas graphics, persistent objects (Tk Canvas, Gnome Canvas)
  • With AA/vector-based graphics (Gnome AA Canvas)
  • With animation (Nautilus Andy-branch Canvas items)
  • With Vector graphics (Gnome Print, librsvg)
  • With A 2D graphics model (PDF, Libart, Cairo)
  • With Web-like-Deployment security (SecureTcl, Tcl Plugin, Java)
  • XAML has been done before (Glade, Qt designer), but am not sure that XAML is the best “authoring” model yet. The power lies in their deployment power.

  The difficulty with the second option, however, is that it will be enormously difficult for any company not named Microsoft to push a new rich client framework. Plus there are the current libary/framework divides between the GTK and QT camps, which presumably would have to be bridged lest the open source approach be fragmented even further.

• Indigo: As it happens, efforts to clone Indigo were very likely what prompted the Microsoft response (see here, with a dispute on that article here). The project, renamed Amber from MonoIndigo, is hosted here, with a corresponding blog here. With a Stephen J Vaughan-Nichols quoting Novell’s PR person as follows, “Miguel and I discussed this a couple of weeks ago, and the answer [is] basically we do not have plans to implement Indigo, so this discussion is more or less moot,” I’m unclear on the current status of the project but I’ve dropped Rocky, the Amber PM, a note seeking clarification.

Q: How significant overall is this announcement?
A: To me, it all depends on the traction that Avalon and Indigo get from a development perspective. Indigo, I think, is a bit further out simply because as a service bus and SOA enabling technology, the on ramp is like to be slow and steady. In Avalon’s case, the potential adoption rate depends on what your opinion is on rich versus thin architectures. Avalon can be viewed if one is so inclined as an attempt by Microsoft to keep the platform – a major revenue source – relevant in an era when thin-client and web based clients are becoming increasingly compelling. I’ve quoted this piece before, but Tim Bray echoes my thinking on the subject here:

On more than a few occasions—most recently in the context of Avalon—I’ve observed here that both IT admins and end-users prefer browser-based apps to traditional compiled clients, for everything except content creation. Every time, I get emails and incoming pointers from people saying “You just don’t get it, the Web interfaces are so tired, we really need a richer UI paradigm.” The interesting thing is that these reactions are always—every time, without exception—from developers. Not once has an end-user type person written in saying they wished they could have a richer interface like the kind they used to have in compiled desktop apps.

Setting that aside, however, ISVs and developers will have to ask themselves whether they’re comfortable committing to a platform that will be Windows only, or whether they’d prefer a cross-platform approach, possibly at the expense of functional richness. It comes down to a question of platform ubiquity, as I alluded to in an earlier piece on Mono. If developers and ISVs in large numbers are still comfortable with a single platform approach, Avalon is likely to become very important very quickly. If the single platform approach is less attractive, then the lack of an Avalon clone is likely to hurt projects like Mono much less.

Q: We’ve discussed primarily Mono here, but are there other projects that might be concerned with Avalon/Indigo issues?
A: Probably several, but one of the higher profile would be Mozilla. See comments from Brendan Eich on the subject here. From an Avalon perspective, there are unquestionably GTK/QT implications (both of which have C# bindings in GTK-Sharp and QT-Sharp), not to mention lots of other projects like Cairo or Glade.

[1] I am aware that Avalon will ship on non-Longhorn operating systems, but as I understand it it will be in reduced fashion.