Mono's Making Money
gigaom.com
gigaom.com
Incidentally, I think this is the best way to start a business if you ever find yourself in the right position. Big companies are ditching / spinning off successful products which are just not "successful enough" and you can often pick them up for the cost of supporting existing customers.
I surely would hope that the same think had happened to several of the Google services that were killed a short time ago; specially Wave and Code Search.
Although I know that at least Wave was made given to Apache, I think what that needed was a company that was willing to polish and provide the service.
1: Those products are build to run on Googles infrastructure, which you can't have if you're not Google.
2: Those products don't have customers, they have users. That makes spinning a profitable business off much harder.
Not necessarily. At least with Google Wave [1], Google ensured that they made the necessary modifications to allow users to run Wave servers by themselves. There is at least one provider running wave-in-a-box [2], and there isn't any reason that this provider should be the only one.
>2: Those products don't have customers, they have users. That makes spinning a profitable business off much harder.
Harder yes, but it's still well short of impossible. I was thinking that the Wave Federation Protocol could perhaps be monetized as a shared-editing/collaboration service. It could be positioned as a combination of Sharepoint and chat.
[1] http://googlewavedev.blogspot.com/2010/09/wave-open-source-n...
In the case of Wave, there was a major gap between the product being declared EOL from Google and until the various bits and pieces for running Wave as an independent vendor was in place - and in that gap all reasonable people ran away, so non-Google Wave offerings are starting from scratch.
As for money, no, certainly not impossible, but it's one more hurdle to hitting the ground running.
That's pretty cool. From the article, it sounds like they were cash-flow positive enough to support 50 people, from the outset.
That should happen about fifteen minutes after never.
Except, said patent grant does not extend to people who don't work for de Icaza, people who distribute Mono, or people who use Mono, or people who have compiled C# apps with Mono.
Microsoft refuses to make Mono patent free, and anyone who distributes, uses, or distributes binaries compiled with Mono _can and will be sued_.
Not only is de Icaza not a competitor to Microsoft, he is helping Microsoft attack Linux and the Free Software movement.
Mono refuses to switch to a license, such as GPLv3, to protect users, distributors, and developers from the patents; not only do they refuse, they are getting rid of all GPLv2 code in favor of BSD code. Once Mono is BSDafied, Microsoft can import all code from Mono and close source it within the main C#/.Net implementation on Windows.
http://www.mono-project.com/License
The fact that C# programmers can code for multiple platforms thru easier porting makes them more likely to explore OSS options instead of staying solely in Redmonds garden.
So, again, how does that license protect open source? It is neither GPLv3 or ASLv2, nor will Microsoft stop using patents to attack people.
I'm not sure how I can interpret it any other way. Being sued by Microsoft is something no one wants.
That said, the code donated by Microsoft has been under Apache2 which does provide patent protection, just like GPLv3.
So, yeah, Microsoft is very interested in trying to make their core product faster so they can catch up to other solutions such as native code (C/C++) or Java (C# is still typically much slower than Java).
Oh, and Mono can also compile to AoT binaries, which do not require Mono/.Net installed on the target system, such as being able to target iOS under Apple's anti-VM policy.
Microsoft is very interested in all of these.
- Microsoft's CLR is vastly more sophisticated than Mono, involving millions of man-hours work, unless you show me a benchmark I have absolutely no reason to believe it executes bytecode faster, especially given that Microsoft Research publish papers on fast JIT [1].
- Mono still doesn't have a stable generational GC [2], I hope you like memory leaks and long pauses.
- .NET can compile AoT binaries, and does this for all built-in libraries using ngen [3]
In conclusion: Microsoft have no interest in any of Mono's technologies.
[1] http://research.microsoft.com/en-us/projects/spur/
[2] http://mono-project.com/Generational_GC
[3] http://msdn.microsoft.com/en-us/library/6t9t5wcf(v=vs.71).as...
Not that I want to defend Diablo-D3 (he's a troll), I do want to make a few slight corrections to your comment.
1. You are correct in that Microsoft's .NET VM performs better than Mono overall (at least in the general case), but Mono does perform better than .NET in some cases.
Unfortunately I don't have a list of the areas where Mono outperforms .NET handy, so I can't list them here. Perhaps one of the other Mono devs can follow up and provide details. Most likely SIMD would be on the list.
Whether Microsoft would be interested in taking Mono's implementation for these areas or not for their own VM is questionable. Likely not, as it would likely not be easily adaptable to their implementation anyway.
2. SGen is actually stable these days. It is used in Mono4Android and we are working on moving MonoTouch over to SGen as well.
Moonlight was also being moved to SGen (it started out using Boehm because that was the default GC when the project was started) when the Novell layoffs came along.
As responsible developers, we have been taking our time moving to SGen as the default GC because we don't want the move to break any existing apps if we can avoid it. As with all new things, there are still likely to be bugs here and there, but overall we feel that it is ready for use and we've been eating our own dog food.
3. As was mentioned in another comment already, Microsoft's AOT isn't quite the same as Mono's AOT which allows generation of binaries that do not require an external CLR to run.
There was once an entire company called Xenocode, founded by ex-MS devs, and built on the idea that it would be really useful to distribute .NET apps without the CLR. They had a tool which could do this, even with ngen'd assemblies. Turned out it wasn't so useful. They've now pivoted into enterprise application virtualisation, and their offering is similar to Softricity, which later became Microsoft App-V.
I would say that Xenocode's failure wasn't so much that no one found .NET w/o a CLR useful, it was that they likely only supported Windows.
Oh well, Xenocode's loss is our gain :-)
Mono's new gc is quite solid now. Mono for Android customers use it by default.
Yes, performance is not the best nor does it support a concurrent mode. But a garbage collector is one of those projects that is never done and always have an infinite amount of work left. Our gc has been improving a lot and the next release, for example, features a lot of scalability and performance work.
Said that, if you compare it to other gcs offered on mobile environment we're doing very well.
Mono features a much simpler JIT and runtime and this is a competitive advantage for us or do you think MS ships its desktop/server VM on winphone? We do, and it has teached us a lot about how been slim and simple makes you much more adaptable.
Now on the subject of AOT, mono features a much more sofisticated system than .net, it's the only one that supports running without a JIT while retaining generics.
BTW, I work for Xamarin but those are my personal opinions on the matter.
This claim is completely fictitious.
We started an effort a few years ago to migrate MonoDevelop code to LGPL and MIT/X11 (not BSD) from GPL. Our reason for doing so was to make it possible for third parties to write extensions (addins) to MonoDevelop and license it under whatever license they wanted, i.e. we did not want to force them to have to develop their addins and license them under GPL if they didn't want to.
It was not some big conspiracy to prepare for some Microsoft takeover or anything.
MonoDevelop, MonoTouch, and C# have been an absolute pleasure to work with. Completion is insanely fast, with fuzzy matching. C# delegates make implementing event handlers a pleasure. The integration with Interface Builder is a bit shaky at times, but I suspect that may be a bug in XCode.
This makes me wonder what other projects in a similar situation could make a similar jump.
If you are looking for a home in development but don't yet need to take the plunge of finding a job. This is a good example of how an open source project can create opportunities.
Under Runtime Notes Improved tail-call support for the F# compiler.
Not enough information to determine if improved means fixed.
Chromebooks already have a beta version of this, and Chrome will ship with the plugin on all platforms eventually.
I don't think the argument that their DRM is exposed to a lot more risk by presence on desktop Linux is legitimate. Someone can break it on Windows or Mac without much extra effort if they cared to break it.