Miguel de Icaza is living the life right now. He managed to get Novell to fund his idea and then effectively bought it off of them for a steal. Well done!
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.
>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.
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.
The mechanism the OP referred to was picking up an existing product and providing a more or less uninterrupted user experience. It's a great benefit for a start-up to be able to hit the ground running with a user base and traction.
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.
How willing companies are to do it seems to vary. A colleague of mine would jump at the chance to buy his now-defunct project from his former employer, and had lined up some funding to do so, but they don't think they'd make enough money spinning it off to be worth the hassle, so are just sitting on it instead, in case the IP might come in handy at some unknown point in the future.
"As a result of garnering the rights to Mono and a solid customer base, Xamarin wound up with self-sustaining revenue that covers its staff of some 50 people — without having taken on any venture capital."
That's pretty cool. From the article, it sounds like they were cash-flow positive enough to support 50 people, from the outset.
They now look like direct competitors to Microsoft - providing tools for iOS and Android devs and kind of distracting them from W Phone. Do they have the right kind of agreements to be sheltered from MS anger should it come?
That's one way to look at it. Another way to look at it is that they are allowing developers to develop for iOS and Android in C#, which may eventually have a good effect on the number of Windows Phone apps developed.
OTOH, being able to easily move your WP7 app to Android or iOS is a disaster for MS. The only portability that interests Microsoft is one-way towards their platforms.
Also consider that most .NET developers who target Mono still use and pay for Microsoft Developer Tools. Mono has it's own IDE but it pales in comparrison and at the moment it's not a focus of Mono team.
Miguel de Icaza works for Microsoft, and Microsoft has extended Mono developers a patent license for all relevant C#/.NET patents,...
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.
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.
How is that different from any other OSS project? If MS wants, they could look at a projects source code and decide that they've violated a patent and sue them. To my knowledge they're yet to do this.
The difference is that Microsoft created .Net and the patents covering it together, so they're fairly narrow patents and it'd be a hell of a lot harder to find relevant prior art to use against them. (The same's true of OOXML, incidentally; Microsoft even tried to get a patent covering both it and ODF but the examiner narrowed it to just OOXML based on a huge amount of prior art dating back to SGML in the 80s.)
You are reading too much into events. MS likes Miguel because he brings some open source respectability to the NET platform. It is also a potential source of licensing revenue stream in the future. MS has no reason to want someone else's implementation of the CLR and VM.
Mono's VM executes C# bytecode faster than Microsoft's, and Mono's C# compiler produces better bytecode than Microsoft's.
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'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.
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.
Glad to here that SGen is stable now, of course turning it on by default in Mono is the true test of 'stable', but as you say it's reckless to break things needlessly.
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.
Distributing .NET apps w/o a CLR is probably the biggest strength of Mono - it's how Mono is able to work on iPhone, Wii and other devices which do not allow dynamic code generation.
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.
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.
Microsoft is very interested in AoT binaries that don't require a runtime installed? Microsoft has specifically said they have no plans to pursue this path, even though they could obviously do so. The reasons was that they didn't want to deal with patching all these programs that had the runtime embedded in them. I found that sort of a weak argument; they probably just wanted to get higher penetration numbers.
Have you even tried to submit a patch to Microsoft for one of their Microsoft Shared-Source projects (there is a list here: http://www.microsoft.com/resources/sharedsource/default.mspx ), ? It is near impossible to get MS to accept them. They will give away code, but paranoid about taking contributions.
> not only do they refuse, they are getting rid of all GPLv2 code in favor of BSD code.
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.
It makes me unfeasibly happy that they have achieved a self-sustaining business model. I wouldn't necessarily have predicted that I would feel this way, but it makes me trust them more.
I've never seriously used C# before, but the desire to build an iPhone application, combined with my unfortunate distaste for Objective-C, recently led me to MonoTouch.
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 is a great story about a project finding a way. It's also great story of a team of talented developers being able to create a commercial force in very little time. I suppose having a well oiled development team and a ton of contacts for possible clients ready to go is a strong ingredient for quick profits.
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.
Netflix will not run on your Linux desktop because Microsoft refuses to issue licenses for its DRM components for Moonlight/Linux desktop. These components run fine on Linux -- look at Boxee et al -- but Microsoft refuses to license the DRM for use on Linux desktops. While I would have thought the spite would run deep enough to encourage a clean room implementation of MS's DRM, I guess most people just don't care since there are so many alternate vehicles that require less work for the same content.
Why is that "except"? It doesn't have anything to do with what I said, really. You could say, "Not for long! Netflix is dropping the Siverlight plugin..." or something like that.
Is there a successful (and by that, I mean not entirely useless) DRM system for Linux? I would imagine that MS would not want to provide the source for their DRM component for fear of it being broken.
Is there a successful DRM system for anything? Again, I think the DRM that remains unbroken is unbroken because there's no point in cracking it. MS's PlayReady protects music and movies, so there's no reason to crack it since you can just rip the DVD/CD instead.
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.
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.