The fact that this is identifiable from the title as a MS PR piece means that most HN regulars completely lack the desire to respond.
The very idea that the question is being asked is enough to indicate that any discussion would be pointless. Clearly, this person has a diametrically opposed worldview, and is going to try and win me over with arguments based on that worldview.
Cost of my "stack": $0. A free OS, a free IDE (emacs), free tools.
Well, I guess I paid for photoshop. ;)
Compared to PHP or Django (which we also do consulting in), ASP.NET is just plain faster to develop in. I can get my own stuff out the door quicker, which means that I can bill more of my time to consulting clients, which means that I'm net ahead at the end of the month.
So I guess you need to stick opportunity cost into that equation to see where you actually stand.
I'd love to see any info backing this up.
Personally, I consider it a slight competitive advantage that so many shops avoid Microsoft stuff on ideological grounds. If they never try it, they'll never know. And we'll have that slight edge in getting things to market faster.
Maybe the problem is your competence rather than your tools? I don't mean to be blatantly offensive, but wow, asp.net > django? Really? ... Man..
6 months later I was quite fast, and could compare apples-apples the things that Django doesn't quite do as quickly or elegantly as our home-rolled ASP.NET framework (which, to be fair, has been in development a lot longer than Django.)
So yes, having given both sides a decent shot, I went back to ASP.NET. As I said above, your mileage may vary. But until you've put in the time to build something big with .NET and get fully up to speed, you'll never know if you're right.
You make cool stuff, I wish you all the best with it, catch you at a beach retreat some day. :)
Client-corporate-intranet-land is completely divorced from the realm of what is possible. That entire world enforces such silly requirements on you that, well, maybe it is better to use .NET.
But who wants to work in that kind of an environment?
Who wants to use the MS tools to manage their servers?!? I'll take Puppet and Monit, thanks.
Opportunity cost? I develop with a REPL right there in emacs, so I can see how the running dev-server code is working, able to instantly see the effects of what I'm doing. Once I've got it where I like it, I type a single line, and my tests run, and if they all passed the app deploys to staging.
Where's the room for opportunity costs?
It's just your regular emacs + ruby(merb) workflow.
Merb console in one buffer for a repl-a-like (you can do more of a "real" merb repl if you want, starting the merb console from a ruby buffer in emacs, so you get the benefits of built-in ruby-mode for evaluation of forms at point, etc; I never use those shortcuts, so I use a regular old merb console running in an emacs shell, and either type into that or drag code from a code buffer when I want to see the effect of code live for some reason instead of just saving the file and letting merb auto-reload, which is default behavior).
The 'test, deploy' is just a rake task that wraps a capistrano deploy task (which is usually 90% wrapping git, heh) in a conditional: call the deploy task if rspec succeeded. Easy-peasy!
It's a joy.
Anyway, I don't see how the lack of .NET could even remotely be costing me ... anything. This is the standard way of developing for a LOT of people, you write the code, you deploy it if it doesn't break, you do it all with as few keystrokes as possible.
Of course, I'm sure one can concoct horror scenarios built upon stupid coworkers and unmaintainable scary piles of text and inscrutable shell scripts and lions, tigers, bears etc.
Well, don't work with idiots, and the FUD vanishes into thin air. Plenty of complex open-source projects thrive on a foundation of hardly more software than (vi,emacs) and (git, svn, whatever), so manifestly these tools are no obstacle to coding awesomeness.
As I said in the root: Microsoft PR piece.
Wasted time upgrading / relearning OS because MS has end of lifed it and requires new OS for tools to run.
Wasted opportunity when you discover there is market outside win32 but it's too expensive to target cause all your products/libs/experience is invested into a proprietary stack. Vendor lock in is expensive in other ways as well.
Inability to find/fix bugs in stack cause it is closed source.
Inability to tune/add feature/etc stack cause it is closed source.
Those are some of the first that come to mind. There have been essays, articles, papers, and blogs galore written about how and why closed, proprietary < open / standards compliant. I'm sort of stunned anyone reading HN needs to schooled in that.