Node.js SDK for Windows Azure on Github
github.com
github.com
Then there are also other articles on consuming Azure services with clients written in many languages. http://blog.smarx.com/posts/windows-azure-storage-libraries-...
Besides, supporting third-party technologies on Azure and reimplementing open-source programming languages on top of the .NET framework seem tenuously related at best. That's actually one of the advantages of having a corporate agenda in my mind: things that are unlikely to gain traction with developers can be cut with impunity. It prevents fracturing and slowing down communities, all too common in the open-source world (think of the many, many variants of Lisp, or the recent explosion of LanguageX-to-javascript compilers).
These technologies are cheaper to implement elsewhere (Linux, other cheaper cloud providers, etc.). So, it seems like Microsoft is simply providing a way for .NET enterprise developers to migrate off their platform while being paid for it.
Why is Microsoft increasing the supply of developers who can write code for non-Windows platforms?
I can't speak for the Azure folks, but I can tell you that as we built WP7 we recognized that one of our biggest challenges was reaching the hearts & minds of developers who had grown up outside the "MSDN tent". It was very clear (to me anyway) that we had to try extraordinary things to engage with those developers.
I suspect the Azure team is thinking the same way. It's pretty clear that being insular isn't going to work anymore.
But, WP7 demands an SL/XNA and .NET background. It seems like reaching non-Microsoft developers was/is a tall order whereas iOS can tolerate C,C++ or PhoneGap solutions. Do you feel that Microsoft had some success in bringing people into the tent?
You can contact me at charlie (at) kindel (dot) com
Of course Microsoft does have some large strategic goals for its public conduct, but is it really such a stretch to allow that the Azure team wants to embrace developers outside of their traditional base? So long as it doesn't conflict severely with some other goal of the company, I don't find it difficult to believe that an enterprising manager on a mission could push through a project like this. Interoperating with a fledgling open source project for mutual benefit, even though it might not be a traditional tactic employed by Microsoft, is certainly not a particularly hard pitch to sell. Particularly if it's not a heavily politicized open source project.
For example, let's not forget that both Microsoft and Google donate millions each year for academic research into computing -- stuff that is way far out, such as trying to find viable quantum computers. These companies have giant market caps, and even though Microsoft may have a corporate edict to stamp out Linux wherever possible, and Google's profits are directly affected by how much creepy info they can gather on you, these companies are made up of a bunch of humans, and you have to expect that at least a few of them can scrape together altruistic and benevolent projects.
This doesn't mean Microsoft is somehow out to kill or abandon .NET as I've seen some panicked .NET developers speculate recently, but it does mean they want .NET to be firmly in support of their platforms and not the other way around, and if there's a choice between doing something that will help .NET and something that will help Windows et al., they'll take the latter.
In terms of "openness vs. lock-in" this is probably a lateral move - they're more open to Windows et al. being less locked into their tools (or their tools' revenue streams - e.g. the tools for Windows Phone and Win8 Metro style apps are a free download), but less open to their tools being less locked into Windows et al. (e.g. cross-platform Silverlight), or even the latest version of Windows (e.g. .NET 4.5 is Win7/8-only).
You can easily RDP into azure instances, so you could do that from linux if that's what your asking.
Or, if you're talking about managing your resources (e.g. spinning instances up and down) all of that stuff can be done via REST api. If there isn't a unix toolkit yet, there will be one. Tooling seems to lag feature development in Azure by a bit.