If you are attending PDC or at Microsoft and love Mono, .NET, Open Source, Linux, MacOS, iPhone, Silverlight, Android or WP7 and want to hang out, discuss, or debate the finer points of trollcats in contemporary society, drop me an email at [email protected].

Alternatively, we can also indulge in some Java-driven schadenfreude or debate whether chubby pixels are worth staring at.

I will be in Redmond from Tuesday afternoon until Friday night.

Yesterday, Jason Zander announced that the maintenance and future development of IronRuby and IronPython languages was being turned over to the Iron* communities.

Microsoft reached out to some of the users of the Iron languages to take over the coordination for these projects. Together with JB Evain, Michael Foord, Jeff Hardy and Jimmy Schementi I agreed to help coordinate the future development of these languages. The Iron* community reaction to the opening of the process has been very supportive judging by the emails on the mailing list and the twitter responses.

There are four pieces of code involved, all licensed under the Apache 2.0 license:

• The IronPython Python implementation
• The IronRuby Ruby implementation
• The Iron Python Tools for Visual Studio
• The IronRuby Tools for Visual Studio. This one is a new source code drop.

Both IronPython and IronRuby will be developed like other open source projects without any of the limitations that previously existed. In particular, from my very Unix-centric view, we will be able to get the proper fixes into the Iron* languages to make them work out of the box on Linux and MacOS.

Our Contributions

Although we will help with the coordination efforts in the Iron languages as the community grows and evolves, we have some concrete tasks that we will be working towards right away:

• Ensure that the Iron* languages build and work out of the box on Linux, MacOS and Unix.
• Use Mono's Continuous build system to keep an eye on any regressions on IronRuby and IronPython.
• Package the latest IronRuby and IronPython for Linux and MacOS.

Opportunities

Ruby and Python make programmers happy. They bring joy and smiles to programmers everywhere in the Unix world. Both have strong user bases on Linux and MacOS and there is a strong ecosystem of independent implementations for both Ruby and Python, each with their unique features.

In Iron's case the major feature is being able to use your scripting language of choice while having access to all Mono APIs for building standalone applications or for extending existing applications like MonoDevelop, F-Spot, Banshee, SparkleShare and Tomboy.

From my Unix-biased standpoint, this means that all of the libraries that we have been working on over the years from Gtk# for building desktop Gnome apps, to MonoMac for creating native Mac applications with the entire universe of .NET libraries at your disposal.

The Iron* languages, combined with our MonoMac will make an appealing platform for building apps for the Mac AppStore.

Another fascinating project is the Pyjama Educational Project. Pyjama is written in IronPython, Gtk#, and GtkSourceView and currently supports 5 DLR languages.

Teaser

As the announcement came out last night, Geoff Norton cooked this simple teaser of IronRuby on the iPhone.

Check it out here.

Microsoft has three big tasks ahead of itself: (a) make Azure successful; (b) make Windows Phone 7 successful; (c) keep the existing Windows and Office businesses printing money.

There is probably not a lot of political support at this point to embark on more large-scale innovations at Microsoft while there are probably hundreds of smaller innovations that are waiting under all of their product groups.

Ray Ozzie incubated a number of projects like Azure and Mesh at Microsoft that once they reached a level of usefulness were transferred to the product groups.

He is probably leaving his position as Chief Architect at Microsoft as he transfers the Azure assets to the product group and he is once again left as a general without an Army. Starting new project and recruiting teams from scratch for new products has probably taken a toll on him and he is ready to move on.

Missed Opportunities

Back in June I blogged about what I would do if I was in charge of Windows 8: among other things, I would have created a Windows AppStore.

This AppStore would have helped independent ISVs tremendously by opening the entire Windows user base as potential customer for Microsoft's products. It would have helped Microsoft make Windows even more relevant, and it would have done more to push native applications on Windows than anything else they have tried in the past.

The Windows PC market is a market that is many times larger than today's iPhone market. It would have been a gold mine, and there would have been a renewed gold rush to ship "Windows AppStore-ready" applications for Windows.

Hundreds of people at Microsoft must have had this idea, the question is why it never bubbled up to the top?

Short of a Microsoft-powered AppStore, Intel has announced that their Windows Appstore will now include .NET software.

On the one hand, Intel has now given up any attempts to make their AppStore be a cross-platform app-store, which I felt was a gracious thing for them to do, as it would have helped Linux.

Financially, having a strong Windows-based appstore was probably the right thing to do for Intel. There was really no point in Intel undermining his own efforts by forcing people to use cross platform tools in the first place.

If Microsoft was the one providing the AppStore, they would be reaching a much bigger market than what Intel hopes to reach.

This could have been a great Ray-Ozzie level hack to pull at Microsoft. In the meantime, Apple today announced an AppStore, and they are going to get a bucket of apps and a bucket of developers to push software on their platform.

Live Mesh

Live Mesh had a lot of promise, but sadly, the groups working on it refused to open up the specs on time, and the product became fairly uninteresting over time.

If you are going to open something for the world to see, you should be ready to let the world interoperate with it from the start. Otherwise you merely give your competitors the good ideas, and they throw away your bad ideas and avoid paying any of your strategy taxes.

Happy days at Mono Central. Just a few months ago we decided that we should apply the lessons learned from MonoTouch to Mono on the Mac and we built a new set of .NET APIs for developing native Mac applications. We called this MonoMac.

We recently brought tears of joy to developers by shipping it.

MonoMac will be a great tool to build native Mac application using your favorite .NET programming language.

We clearly have to take this to the next step as MonoMac is merely a binding to .NET. We are going to have to extend MonoDevelop to create fully self-contained applications that embed both your application, any library dependencies that it needs as well as the Mono runtime.

The above really had not been my priority, as far as I was concerned "Download Mono and Install it" was a perfectly suitable solution. So you have Apple to thank for my change of heart.

Hopefully we will have an experience as smooth as the MonoTouch experience has been.

As part of our efforts to bring a superb developer experience to every platform in the world, we have made a new release of our bindings to the MacOS X APIs: MonoMac.

We know that Mac users like to have a smooth installation experience, and we have worked hard to make this as simple as possible. Currently MonoMac is still not a 1.0 product, this is what developers need to do:

• Install Mono for OSX.
• Install MonoDevelop.
• Add the MonoMac repository to MonoDevelop.
• Create a MonoMac project.

The result is a .app that you can distribute to your users.

The MonoMac API design is inspired by work that we did for MonoTouch.

We have achieved a beautiful blend between C# and MacOS that will turn Mac developer's tears of pain into tears of joy.

Community

Update: to get started with MonoMac, you can join other MonoMac-ers on the IRC channel #monomac on server irc.gnome.org.

We use the mono-osx mailing list to discuss the binding.

Hackers

If you want to get your hands on the source code for MonoMac, head over to GitHub and download both monomac and maccore. The former contains the MacOS-specific bindings, while the latter contains the shared code between MonoMac and MonoTouch.

The introductory post to MonoMac still contains many useful links and design details, you might want to read that if you want to hack on MonoMac.

Contributors

Our API coverage right now is very complete. We will certainly add more C# features to the binding as we learn how developers are using the API, but that is a bit of an organic process.

One area that we need help to improve the developer experience is to fill-in all the "summary" sections in our documentation. This information is shown during auto-complete/intellisense for the developer for classes, methods, enumeration values and properties.

Details on how you can contribute to this are on this post of mine.

Read David Mitchell's experience in using Mono to reuse code between the Windows and Mac platforms.

We have just released Mono 2.8 a major upgrade to the Mono developer platform. This release contains ten months worth of new features, stability fixes, performance work and bug fixes.

The highlights of this release include:

• C# 4.0
• Defaults to the 4.0 profile
• New Generational Garbage Collector
  • Use mono --gc=sgen or mono-sgen to use Mono with the new GC
• New Frameworks from Mono MIT X11 and Microsoft MS-PL/Apache2:
  • ASP.NET 4.0
  • Parallel Framework: including PLINQ.
  • System.XAML
  • System.Dynamic
  • Managed Extensibility Framework
  • ASP.NET MVC 2
  • System.Data.Services.Client (OData client framework)
  • WCF Routing
  • .NET 4.0's CodeContracts
• Performance:
  • Large performance improvements
  • LLVM support has graduated to stable
    • Use mono-llvm command to run your server loads with the LLVM backend
• Version 2.0 of the embedding API
• Removed the 1.1 profile and various deprecated libraries.
• OpenBSD support integrated
• Mono no longer depends on GLIB
• Threadpool exception behavior .NET 2.0

For the full details, check our detailed Mono 2.8 Release Notes