Re: Go C#
I'm not a professional developer - I code, but I don't do it as my sole and only job.
As a user, though, I want it to "just work". I don't particularly care for being tied into any single platform, so all that matters is the end-interface to me, and that it works anywhere. Now that we have web-based technologies, that solves a lot of the problems there. So the question then really becomes "What do we run that site on?", which is an answer few care about outside the company. Sure it can be MS with the licensing and other hassles, but it honestly DOES NOT MATTER.
Which I think is why a lot of non-coders / amateur coders don't get why you'd then go with MS. Running ASP.NET, you'd never Server 2012 back-ends. That's a licence cost and a bit more right there. Then you'll need SQL (although, as you say, there are other alternatives and then we get into things like Azure). C# development tools basically require some piece of software from one company at the moment (you said it yourself, VS), and who knows how long they'll be supporting it or what they'll do to it (did you witness the evolution of VB at its beginnings?).
All of these are expensive, tied-in commodities that have a vast range of knock-on effects (if you do things PROPERLY, you should never need your users to have .NET Frameworks installed, or use a particular browser, but it's increasingly common for such things to slip into client requirements for software that absolutely DOES NOT need them as they are only a front-end to something else).
Sure, you *might* get better productivity with the right, very expensive, tools, but it's not out of naivety that some people see that and recoil, where a 1980's--terminal style interface would cost them nothing, with an ongoing licence of nothing, and a license audit cost of nothing, and where back-end development, although a skilled task, has specialised tools that are specific to the case but can ALSO be ripped out and replaced with anything else with minimal cost (e.g. just as analogy rather than a real-world example, replacing MySQL with PostgreSQL, or Apache with something else, or Linux with FreeBSD or WHATEVER).
The world today (and historically) means that NOTHING on the back-end matters to the user, so long as they get the interface they need. Which leaves it down to developer preference vs cost.
The interfaces are commonplace now and everyone knows how to work a web-based app, or even a dedicated app on their smartphone, or whatever. The question really is: How do you want to get there? By buying into MS and betting your business on them and their increasing licence and maintenance costs, or seeking alternatives that MIGHT be a bit more uncomfortable to code on if you're not used to them but are much more flexible in their execution and can be moved onto other platforms and other cloud providers as needs change?
It's that that really causes amateur geeks and people who don't code all day long to look up and think: Hold on. I'd rather put in more effort with less popular tools and end up with something better in the long run. There's a reason that an awful lot of OpenSource software does not come with a VS project file. Because it's never touched by one, and when it is, it's solely for building the Windows executables. I seriously doubt that a whole breed of operating system, driver and application programmers for huge, mission-critical, global pieces of software are struggling with sub-standard tools "just because" they are free. They either buy something in to fix the shortcomings (there's nothing wrong with buying a tool to save you time on a job), or the tools are perfectly fine.
Fact is, almost every piece of software I deal with as a user / IT guy that has gone down the .NET route has suffered from it. We've abandoned several companies as they announce that the next version of their software will be Silverlight/.NET based and gone with alternatives (sometimes more expensive but not always) that don't place restrictions on us.
In some cases they were only able to recoup their customers by moving to web-based things where THEY had to deal with all the problems of which service packs were installed, etc. And then they often found that the cost of using those tools is more expensive than just buying a coding team that are prepared to put in the work and getting a nice, modular, portable, flexible codebase on something they can swap out any day.
The OP is asking about cross-platform stuff here. That's because his users are probably requesting cross-platform tools, which is an indication of how much they want to put trust into any one entity or system type, or even deciding whether to do most of their work on their PC or their phone (a blanket decision like that can kill the flexibility of a workforce). They are asking for that for a reason. And although not a requirement, it pays to think about why they are asking that and whether the same reasons should apply to the back end that NOBODY but yourselves have to manage. If users aren't putting their faith in having a single environment around next year, why should your developers and their network support? It then makes sense to code things in a similar way, to provide modularity and flexibility.
If you base code on C#, ASP.NET, Windows Servers and Azure, you lose a lot of that almost immediately. You're forever condemned to code only on such platforms and run your code only on such platforms, even if your users never know that. Sure, if you insulate and modularise properly, it will never be an issue (and it is MUCH easier to find a C# programmer in the business world) because it will never leave your company, but you have to cost it properly and that includes the savings such tools will give you over their alternatives. Does C# *really* save you that much time over C++ or Java that it's worth committing an awful lot of resources to a product-lifetime running MS software for everything from the OS upwards, even internally? And the answer to that is NOT a simple Yes or No, but depends on a myriad factors to do with the kind of application, the kind of business and the scale of just about everything.
It's really a business-case decision, in terms of how you code. And in those terms, I could make a business case for coding my stuff in an MS-only environment with MS-only tools for deployment on MS-only machines, of course, but it would really grate against my better sense when there are alternatives that don't tie my coding to a single platform.
I would have serious concerns about the longevity of any coder that can only code on one platform, not just from an obsoletion basis but just simple concerns about what they will do when other changes are needed.
Biting the hand that feeds IT
