As Mono grows on servers, mobile and desktop platforms, we are looking to hire programmers to join our Mono Runtime team.

The Mono Runtime team owns the code generator, the just-in-time and ahead-of-time compilers, the garbage collector, the threadpool and async layers in the runtime and mostly works in the C-side of the house.

If you are a developer with low-level experience with virtual machines, just in time compilers or love garbage collection, real time processing, or you read every new research paper on incremental garbage collection, hardware acceleration, register allocation and you are interested in joining our young, self-funded and profitable startup, we want to hear from you.

Send your resumes to jobs@xamarin.com

We have historically made stable releases of Mono that get branched and maintained for long periods of time. During these long periods of time, we evolve our master release for some four to five months while we do major work on the branch.

Historically, we have had done some of these large changes since we have rewritten or re-architected large parts of our JIT, or our garbage collector, or our compilers.

There were points in the project history where it took us some 9 months to release: seven months of new development followed by two months of beta testing and fixing regressions. With Mono 2.6 we tried to change this, we tried to close the release time to at most six months, and we were relatively good at doing this with 2.8 and 2.10.

We were on track to do a quick Mono 2.12 release roughly around May, but with the April bump in the road, this derailed our plans.

Since 2.10.0 was released two things happened:

• On Master: plenty of feature work and bug fixing.
• On our 2.10 branch: bug fixes and backporting fixes from master to 2.10

Now that things have settled at Xamarin and that we are getting Mono back into continuous integration builds we are going to release our first public beta of the upcoming Mono, it will be called Mono 2.11.1. We will keep it under QA until we are happy with the results and we will then release Mono 2.12 based on this.

But after Mono 2.12, we want to move to a new development model where we keep our master branch always in a very stable state. This means that new experimental features will be developed in branches and only landed to the master branch once they have been completed.

Our goal is to more quickly bring the features that we are developing to our users instead of having everyone wait for very long periods of time to get their new features.

New Features in Mono 2.11

These are some of the new features availalable in Mono 2.11:

• We refactored our C# compiler to have two backends one based on Cecil, one based on Reflection.Emit. Fixing some important usability properties of our compiler.
• Implemented C# 5 Async.
• Our C# compiler has TypedReference support (__refvalue, __reftype and __makeref).
• Our compiler as a service can compile classes now and has an instance API (instantiate multiple C# compiler contexts independently).
• Added the .NET 4.5 API profile and many of the new async APIs to use with C# 5.
• Improved our new Garbage Collector: it is faster, it is more responsive and it is more stable. It has also gained MacOS/iOS native support.
• We made System.Json available on every profile.
• We added Portable Class Library support.
• We added tooling for Code Contracts
• We added a TPL Dataflow implementation
• We added fast ThreadLocal support
• We brought our ASP.NET implementation to the year 2011 and it now sports a new enormously cute error page as opposed to that error page that we have which transports you mind back to 1999.
• Mono's debugger now supports attaching to a live process (deferred support)
• Our socket stack is faster on BSD and OSX, by using kqueue (on Linux it uses epoll already).