BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News The Death and Rebirth of Mono

The Death and Rebirth of Mono

Leia em Português

This item in japanese

Bookmarks

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.

Funding

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
  • Training
  • 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.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Great News

    by Richard Clayton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I'm glad to hear that Mono is not dead; I think many of us cross-platform developers were a little worried about the potential death of the project. Is Xamarin going to accept donations to help get it off the ground?

  • Good news

    by Dan Tines,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This is a better scenario than being under the uncertain umbrella of Attachmate. The only better scenario would have been if Novell had let Miguel and crew spin off the Mono division a year ago, like Miguel had wanted.

    It's real interesting how Mono has a found a niche on the client.

  • Clarifications

    by Jonathan Allen,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    For those of you who don't know, Mono is a mixture of closed and open source components. The core is open source, but the iPhone and Android components are not.

    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.

  • Re: Clarifications

    by Stefan Wenig,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I don't think they plan to license the LGPL parts, it's not even clear if they could. (After all, they could just buy the proprietary Touch stuff too instead of rebuilding it, but Miguel makes it sound like they wouldn't even know who to talk to...)

    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.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT