The Death and Rebirth of Mono
Novell Mono is officially dead. All of the developers have been let go and the new owner, Attachmate, has not expressed any interest in maintaining the project. But in true open source fashion, a new fork is rising up. Led by Mono’s founder Miguel de Icaza, a new company named Xamarin has been founded.
Like Novel Mono before it, Xamarin’s focus is on commercial .NET offerings for iOS and Android. They will of course continue to contribute to the open source Mono runtimes, which forms the technological base for their commercial ventures. They are also exploring the possibility of offering Moonlight in the mobile and Mac app stores.
Xamarin does not have access to the non-open source components of MonoTouch and Mono for Android. While it is a possibility, “they do not seem in a position to move at the speed that we need”. Miguel goes on to say the he and the original Mono team expect to be able to release the first preview of their iPhone product in three months and Android in four.
Legal Concerns for Xamarin
Miguel has also stated that their new products would be source-compatible with existing MonoTouch/Mono for Android code. This brings on the specter of legal action by Attachmate. While there has always been the thought that Mono could be sued by Microsoft, such as lawsuit would require Microsoft convincing a court that it was “just kidding” and the CLR/C# patent covenants are non-binding. Between their obligations to the ECMA standards body and the legal principal of equitable estoppel, the chance of this happening is slim to none.
Attachmate is a completely different story. Even if they aren’t supporting it, they do own a product that is in direct competition with Xamarin’s future offerings. Without some sort of legal arrangement between Attachmate and Xamarin, the latter would face the daunting prospect of proving that their new development doesn’t use any the technology that the old one did. Considering that this is really just a wrapper around the native API, it would be hard to prove you had a clean-room implementation even for a team that wasn’t intimately familiar with Attachmate’s code.
As a result of this, as well as the general uncertainty of any new product, some developers on the mono-android mailing list are stating that they are moving back to Java development for now. Others are holding out as the cost of porting the applications to Java and maintaining two codebases is infeasible for them.
The idea of a company dedicated to just Mono-based offerings isn’t entirely new. According to Miguel they were trying to convince Novell to create a spin-off company for the last year. While that never panned out, it probably explains who they were able to line up a combination of “angel funding” and engineering contracts to keep the new company afloat long enough to develop their commercial offerings.
That said, Xamarin is looking for even more funding to do things such as:
- Tutorials for our various developer stacks
- API documentation for the various Mono-specific APIs
- Dedicated Customer Support Software
- Upgrade our Bug system
- Consulting and Support
- and Marketing: we have a best of breed developer platform, and we need the world to know. Our previous marketing budget is what the ancient Olmec culture referred to as Zero.
Legal Concerns for Attachmate
Turning back to Attachmate, there a lot of unanswered questions about how they will unwind their involvement with Mono. As we discussed last week, Novell’s Mono products came with support contracts that presumably need to be honored. And this isn’t just for existing contracts; it currently looks like Novell is continuing to sell one-year support contracts for both MonoTouch and Mono for Android despite not having any developer resources for those products. If this situation isn’t remedied quickly it could easily lead to allegations of fraud.
It's real interesting how Mono has a found a niche on the client.
Current Novell owns the trademarks for Mono.
Since Mono is licensed under LGPL, which prevents static linking, Xamarin will need to license it in order to do the AOT compilation needed for iPhone/iPad.
The LGPL does not prevent static linking at all. It only requires that the linked product enables you to replace the LGPL-covered libraries with your own. Usually this means shipping your app's object files. I assume they'll find a similar solution for AOT-compiled CLI apps.