I think you miss the point. They already have market. Most Corporate Networks run on Windows Servers. What Mono does is allow those Windows shops with their .Net experienced developers to start experimenting with and hopefully integrating Linux. Without having to change the language and framework they've standardized on.

In that way it gives Linux an inroad it didn't have before Mono.

Yes and no. I think that, given all the money and hard work poured into it, Mono is, relative to other languages and things out there, not as popular as it "ought" to be. Here we have a first-rate JIT compiled language that's completely free (no Java ambiguity), with a team of smart hackers behind it, and yet not that many people use it. I don't, nor do I know anyone who does, besides one of the core developers who lives here in Padova.

Well as the head of an IT department that does use Windows servers I can tell you you're right but the reason has little to do with Mono itself.

Here's the thing you have to understand about corporate IT: Support is king. Unlike startups which are filled with technical people company's have only a few IT people and usually only one whose knowledge is at a high enough level to even think of editing the source of an open source project. So you need to have a support option in place.

Now Microsoft has support contracts but even if you don't purchase one you can get support for $245 per incident on any Windows Server issue. Our agency of 200 computers uses this option once, maybe twice per year. Novell on the other hand offers support for Mono but it's sold in packs of 25 incidents and costs $13,000. So no matter how much Linux and Mono can save your company the outrageous support costs make it virtually unjustifiable.

Indeed - people forget that outside of the software industry itself, software and IT is usually viewed by the business as a cost.

It is a cost. Many IT people/developers like to think otherwise but to do so is truly delusional and can be a roadblock to career advancement.

It may be delusional to not deal with the software is viewed. But the thought that it's strictly a cost is itself a delusion. I have seen firsthand corporations being choked by bad software. (A certain cell phone manufacturer and a certain car rental company come to mind.) I've also experienced good customer service enabled by flexible software, where I'm amazed, "You can really do that?"

Amazon wouldn't be nearly as good as it is if it wasn't for the degree of software quality that they have.

I understand your point and I agree that software could make or break a company. That can be true and you could still make the argument that IT is strictly a cost. That IT departments can enable other departments to reduce their own costs does not change the fact that IT itself is a cost.

In your customer service example IT has clearly had a positive impact, but you'd be hard pressed to convince anyone that the IT department is generating revenue for the company. If you walked into the CFO's office trying to make that case you'd be laughed out of the room. Good customer service does not manifest itself through good software.

A better approach may be to walk into the CFO's office and show how your IT department is helping the company realize it's goal of providing good customer service at an acceptable cost. It's a very subtle distinction. This is what I was getting at when I said not thinking of IT as a cost can be a roadblock to advancement.

If IT is only a cost, and not a competitive advantage, then your company doesn't need IT in house and should outsource entirely.

Being considered a cost and providing a competitive advantage are not mutually exclusive. An IT department that meets its goals at a lower cost than an alternative could be a competitive advantage.

An example of an IT department that's a revenue-generator is Amazon's, in the sense that they sell services outside of the company. But that's quite rare. At most, some IT departments chargeback internally, but that's just made-up money.

Then again, I think it was Bezos himself who described Amazon as a technology company that happened to sell books too.

I'm going to disagree. Based on experience, this is still the root of the problem: "Secondly, support for Microsoft.NET is a secondary goal for Mono"

Maybe Mono is great for smaller agile shops who can somehow work around that (most likely since they don't have a lot of legacy code - or they can start from scratch), but at the big corp I work for it just doesn't work. Many of our teams couldnt get our major projects running without major issues on mono without significant work (which wasn't undertaken).

Mono is unpopular, but I don't think it's because of the negative marketing.

People doing software development on top of Linux tend to choose other languages, like Python, Perl, PHP, Ruby, C++ and Java. That's because these languages have matching cultures and communities.

Personally when I'm investing time learning a tool, if the learning is not trivial, I first take a good look at its community. If you're getting in trouble with Mono, who you're going to talk to?

The core mono mailing list is nice, but other than that you're out of luck. You could join a .NET community for support, but their topics, issues and goals aren't a match for a developer used to work on Unix-related projects. And the signal-noise ratio is rather poor.

"In that way it gives Linux an inroad it didn't have before Mono."

No, it doesn't. For internal development you have a wide variety of options. Java is quite good and very popular among those who consider the option of not running their wares under Windows. The only way Mono can appeal to Windows-only houses is by making it possible to run unmodified (and proprietary) products that run under Windows on other platforms.

Were I insane enough to allow my business to run on .NET and Windows, I would only consider migrating it to other platform if I had the assurance of being able to run it unmodified.

And, BTW, as it is, Mono is a patent minefield. Do you really trust Microsoft to act as a responsible corporate citizen when doing the right thing would cut their profits?

I wouldn't even if acting responsible would be profitable. Playing dirty seems too embedded in their corporate DNA.

"For internal development you have a wide variety of options. Java is quite good and very popular among those who consider the option of not running their wares under Windows. The only way Mono can appeal to Windows-only houses is by making it possible to run unmodified (and proprietary) products that run under Windows on other platforms."

I'm working at a Windows-only house with internally built .NET apps. Mono is definitely part of our long term plans to run these apps on other platforms.

Congratulations. You are the case where Mono makes sense - you can make sure your apps run the same on Mono and on .NET.

Unfortunately, some shops need to use off-the-shelf software that may even run on Mono but is not officially supported and, if something did go wrong, they would on their own.

"as it is, Mono is a patent minefield"

Can you provide the patent numbers of the specific patents you had in mind, or otherwise provide a source for why you think this is the case?

No. Neither does Microsoft who has repeatedly spread FUD over all the free-software and open-source ecosystem.

Can you provide any declaration Microsoft supports Mono and promises will not sue those users not under their IP cross-licensing deal with Novell?

Until then, it is a minefield. And that is what a minefield is about - you never know when you step on one or even if there are any mines.

MS doesn't need to.

1) C# is a standardized, open spec language. Mono is an implementation of that open spec. The development of that specification is driven by MS's .Net platform.

2) Here's a crucial bit of patent/IP law: by releasing the specification of the language to the "public", MS is barred from suing over it in a court of law. So again, there's no need for it say that it won't sue, since it's already prevented from doing so.

Isn't Mono more than the C# implementation, covering much of the whole .NET API, which is not, IIRC, covered by ECMA-334.

And even if by publishing the spec they would have given up their right to sue implementors (which they did not) they would be free to sue anyone that used any technique on which they own valid patents on any jurisdiction insane enough to allow such patents.

And while I doubt their willingness to test such patents in court, I also acknowledge the potential for long and painful lawsuits is more than enough an incentive use other technologies that are every bit as nice to the developer as .NET while negating completely any litigation risk.

I strongly suspect that it would be much easier to port existing .NET code to Mono than it would be to port it to Java. I also suspect than any .NET team wanting to experiment with Linux or Unix would probably prefer to learn Mono's quirks than an entirely new language.