"Possibly the main argument against using Microsoft from the open source point of view has been the issue of expense. However the .NET Framework can be downloaded for free plus they also provide ‘Express’ versions of Visual Studio and their SQL Server
database software which we used and are also free."
This only addresses the development versions of their software. What about license costs for the production instances of Windows Server and SQL Server? That's where costs really start getting prohibitive on an MS stack. For a startup at least.
Before you've launched you can use the development versions. Once you've moved into an office the licensing cost doesn't really matter relative to other expenses.
We spend 13 times more money on cell phone contracts per month at Loopt than we do on MS software licensing (Office, Exchange, Windows Server, VS 2008, SQL Server, etc). Payroll is astronomically more. If the relatively minuscule amount of money you're saving from not licensing MS software makes a difference, I'd argue that you have bigger problems :)
There definitely are valid reasons not to use the MS stack, but cost isn't one of them in most cases. We've saved enough time by using it to more than cover its cost.
[Edit]
For more on cost, look into the Service Provider License Agreement. You pay per month and only for what you used.
That's fine and I even like using .net, but at any point MS can pull a VB6 "not supported" on any technology or part of your stack while it has known vulnerabilities and you can't do anything but chew on it. How can you even put a cost on that?
I agree with your main point ("don't be a sharecropper" [1]), but as for the VB6 example, I don't think this is particularly convincing. It's not like VB6 users haven't had enough time to move over to VB.NET, and if they don't want to, they can still create applications using VB6. Existing VB6 applications are not suddenly going stop working because Microsoft isn't officially supporting VB6. What does 'support' mean anyway?
Actually, a previous company I worked at does have to move away. They have what they believe was one of the largest VB6 apps anywhere. It had its own embedded VBA as well. Now they have an enforced rewrite, and yes, it didn't mean it stops working that day, but they have licenses for VBA which they pass on to customers which DO expire (as in, they can't keep selling their product!). Now they have to move years of work and history to something new. So yes, real companies are real screwed by the decision.
If Microsoft applies the same practice to ASP.NET some day, and a buffer overrun exploit is found, what are your alternatives?
costs may not be the biggest problem, but what about the freedom to make changes to the source (to fix a bad exploit, add a feature, ...)? I still remember the telecom, I used to worked for, being burned by them; we had to pay x thousand dollars for a pre-release patch/bug fix for their black box software...
Speed and quality of evolution/innovation is another factor. MS generally doesn't like open source (their sourceforge clone is a start, but really doesn't go far enough.), and it took forever for MS to catch up to open source with LINQ (and polish it). The same goes for their unit testing and ANT-like deployment tool. (Yes, NHibernate and NANT have been there; but MS pretty much snubbed them instead of embracing them.)
At the end of the day the MS copy machine is fast, but not as fast (or good) as the open source movement.
> it took forever for MS to catch up to open source with LINQ
Sorry to go off-topic, but what were they catching up to exactly? I wasn't aware of anything LINQ-like in open source (not that I'm always aware of these things).
.NET world: NHibernate - NHibernate came out years before LINQ (though a good bit after Hibernate). It was stable and powerful. Besides NHibernate there were other similar .NET open source projects, but I'm not familiar with them
Actually, some of Microsoft Research's Haskell experts have done work to take the concepts from LINQ and port them to Haskell, because it's a cool idea that didn't exist there. Taking monadic combinators and applying them to the problem of generalized querying is indeed something that hadn't been done before.
There are various slick data access techniques available in open source, but LINQ is not a knockoff of any of them.
imho I still feel LINQ is a knockoff and a really late one (years late). to MS's credit LINQ does bring a lot of improvements; mainly in shorter, more concise syntax
the open source stuff (fine - i'm showing my bias against MS with or without good merit)
I'm not saying that you can't build anything good / successful with MS products... and there are situations where going MS is a strong advantage (video games)...
I'm just curious why ppl would constrain themselves (in both flexibility and financials) when there's alternative tech that's comparable (or better)
Which open source stuff -- that's what I mean. I've used ActiveRecord in Rails and a few other open source data access technologies, but nothing I would consider to be a direct precursor to LINQ.
There are a lot of things that Microsoft makes that are derivative of open source -- ASP.NET MVC is effectively yet another Rails knockoff, for example.
But AFAIK, LINQ is something new and different, which is why I'm genuinely curious what you would consider to be similar to LINQ but predating it.
If you're leaving an enterprise job where you developed years of expertise in .Net technologies and wanted to start building on a stack in which you are already an expert.
Having about 3 meetings created per day on average since launch would not qualify this app as a success by any count. For this amount of usage, a shared account on a cheap web hosting service would probably do. Most probably any 32 bit item in my interesting computer collection (if I had any Windows boxes, that is) would be able to carry that load without breaking a sweat.
However, one could not be able to base a startup on this structure, much less a successful one.
The Microsoft platform has worked very well for Loopt as well, though I can't claim we're good enough to have had only two bugs since launch :)
As for cost, we spend less on software licensing per year than we do for our least compensated employee by a substantial margin. We've also had no issues with security thus far (fingers crossed).
Just out of curiosity, why did you choose the MS platform? I mean what advantages did it provide over the open platforms that would actually be helpful for skilled programmers?
I chose Microsoft initially because it's what I knew best at the time, so it was the fastest way to get a working demo out the door. Then I stuck with it because:
SQL Server 2005: The only other options were PostgreSQL and Oracle. MySQL 5 had just come out and all the basic database features I intended to use (stored procedures, foreign key constraints, etc) were new, and thus untested. Oracle cost a fortune (I think I was quoted $65k/core as my only licensing option). SQL Server was a natural choice.
ASP.Net: At the time the only other well tested equivalent was Java, and my brief examination of it led me to believe it was basically equivalent for my purposes. It wasn't worth the switching cost. Rails was really new and also required full access to the database, which I don't grant to our web servers. PHP is extraordinarily difficult to keep clean when working in a team on a large project, so it wasn't really suitable (especially for the cell phone portion, which uses packed binary protocols). Python web frameworks were still in their infancy, or I would have chosen it.
C#: It's fine for a statically type language. I like that it's similar to Java, but a little more relaxed (delegates, unsigned types, etc.). I'm actually a horrible typist (20 WPM on a good day), so intellisense (increase speed) and compilation (find typos) were key. The .NET framework is actually really good and rivals Java's. MSDN docs are much more useful than JavaDocs in that they actually contain examples :)
Now, don't get me wrong. We're not a 100% Microsoft shop. We use Erlang (fault tolerant, distributed session state store), PHP (tile serving), Memcache, Apache (static content and PHP), PostgreSQL, Ubuntu and FreeBSD.
As for open versus closed source, not having access to the Microsoft source code has yet to be an issue. We've had to work around things once or twice (usually because what we were doing wasn't in the spirit of the framework), but we've never encountered an actual bug, and Microsoft's products have always worked as documented thus far. I'd rather not need source access than have to use it to get something working ;)
Ironically, the places where we've had problems are on the open source side. PHP x86 != PHP x64 (same release version, different behavior) on some distributions (cough RHEL cough), and PostgreSQL on FreeBSD 6 is anything but straightforward (max connection limit problems).
I have no idea why (or even how, now that I think of it) you got downmodded (I put you back up)... I think in this day and age if a platform is going to be closed and non-free, it should have to justify those disadvantages. Where does it make up the slack?
Microsoft has done some good work in the last couple of years at making their tools suck a lot less for web development. ASP.NET MVC, a newer framework with a Rails-like approach, is also coming along nicely.
Honestly, the main reason most ASP.NET websites suck so badly is that the Microsoft tries to make its tools accessible to developers who don't want to bother to learn and use web standards, and when used by the standards-oblivious, the resulting web apps are generally very poor in the standards compliance department.
ASP.NET and C# has worked well for Workpost so far. We were able to get version 1.0 online quickly and any issues we've had lately are not related to the platform.
Scaling will be a difficult (but welcome) problem though SQL Server does not have to cost quite as much as most people think it does.
Microsoft could, however, offer more incentives and assistance to startups who choose to use their platform. They've made a lot of progress in the last few years toward being more developer-friendly but they need to go even further.
Finding talented ASP.NET / C# developers willing to work on startups can also also a challenge.
I work .NET in my day job and Rails at night. I feel way more productive working in Rails that in .NET, even though I don't know the Ruby language as well as C# or VB.NET.
I'm interested in playing with the Microsoft stack a bit more, for the usual reasons people play with languages they don't work with. Can anyone recommend a sweet spot to aim at (is ASP.NET MVC really usable yet?) and maybe a book or guide?
When I wrote a sample client to accompany a web service I'd developed, I used VS2005 and a Sams "ASP.NET in 24 hours" book. I suspect seasoned MS stack people would recommend something else.
ASP.NET MVC is pretty close to release, so I wouldn't be afraid of it. If you know Rails or Django, many of the same concepts will be applicable.
Manning has an early access version of ASP.NET MVC in Action that may help you on the book front, but I can't vouch for it. Books for brand new technologies are always a tricky topic. Worst case, there's all sorts of info all over the blogosphere.
The best general-purpose .Net book I have that the moment is Apress's immense Pro C# 2008 and the .NET 3.5 Platform (Fourth Edition). It covers all the general C# and .Net stuff and also has all the new LINQ pieces, lambda expressions, etc.
VS 2008 has some nice enhancements for web development, including some nice CSS debugging pieces that help you isolate where a bit of style is coming from and a decent JavaScript IDE with a debugger.
For database access, you can use LINQ, NHibernate, or the (prerelease) Entity Framework. If you've worked with Hibernate on Java, NHibernate is an obvious choice. Otherwise, LINQ is pretty slick, and there's a ton of information out there on it.
This only addresses the development versions of their software. What about license costs for the production instances of Windows Server and SQL Server? That's where costs really start getting prohibitive on an MS stack. For a startup at least.