Bryan Starbuck, a pretty smart guy as far as I can tell, is wading into a flame war. He’s giving a talk next week at the Eastside Incubator meetup on “Understanding the OPEN SOURCE STACK very commonly used by startups” (longer title: “Understanding the OPEN SOURCE STACK very commonly used by startups and contrasted to .net for Microsoft employees to understand the comparison”).
1) Bryan doesn’t think that the “MSFT Stack” is the best choice for startups.
2) See (1)
He asked for input on the topic on the STS list today, so, rather than just e-mail him, I thought I’d pontificate a bit here.
First, my background: I’m a MSFT guy. Never blue-badged it, but was orange for a while and have worked for startups, professional services firms, and on my own projects using the MSFT stack for a long, long time.
Along the way I’ve incorporated lots of open-source tools and technologies, but I’m near as far away as you can be from an open-source zealot and still be part of the startup community. I’m not a MSFT zealot, either, but I do tend to evangelize a lot of their platform technologies, and for good reason.
They work. They work really well.
I’m teaching a course this quarter at the UW PCE on developing applications for the cloud. At the top of my list of esteemed platforms is AWS, which is essentially platform-agnostic. EC2 instances can run Windows or they can run Ubuntu or they can run RedHat or what have you. Their supporting data and PaaS services, like S3, SimpleDB, SNS, SES, ELB, etc. are all essentially platform-ignorant for the consumer.
Lower, but still viable, are consumer-grade services from Microsoft’s Windows Azure program. It’s essentially got a V1 feel to it, or perhaps a V1.1 feel, but the handcuffs you put on in order to get the simplicity are (IMHO) not worth it for a technically capable startup engineering team.
Much much lower are a large handful of independent open-source platforms that appear to be running on duct tape and baling wire, and which expose gnarly open wounds around every third press of the ENTER key. I won’t name names, but in general, and in my opinion, pure open-source suffers from a key philosophical problem:
1) What’s the incentive to make a polished, quality, bug-free product?
You know, the kind that startups can rely on and not be up at night worrying that their newfangled distributed database is going to lose their data. The kind that let the startup guys focus on how they’re going to make money, not how to get that RPC call working just so.
Companies who make money have an incentive: they get paid. If they do it well, they get paid A LOT. As much as I criticize unchecked, predatory capitalism over coffee with friends, essentialist free-market capitalism provides really clear and measurable incentives.
Open-sourcers, particularly the wacky, lovable “free as in beer” eccentrics, don’t have those same incentives. What then?
Garnering the esteem of their peer group?
Making a living off of services and offerings directly related to the open-source project (the RedHat / Cloudera model, if you will?)
Hm. All three reasons have their adherents, but *common* examples of each are the exception, not the rule. For every successful open-source project that succeeds despite zero (as in zero beer) income, there are dozens (hundreds? thousands?) that end up as abandonware. I’m trying to remember the citation, and can’t, but recently somebody quoted the number of projects or KLOC on SourceForge or CodePlex or somewhere that had been abandoned. It was huge.
Getting back to the central point: Bryan asked some questions in his email to STS. Here are my answers:
Strengths of the .NET & C# stack:
- Best-in-class development environment
- Robust, mature, yet still fast-evolving language
- BizSpark gets you off the ground for 3 years for essentially free
- Excellent corporate support and longevity
Issues with the .NET & C# stack:
- You’ll be recruiting from a smaller pool of candidates
- No cross-platform (even with *ye gods* Mono). Note that I consider this a good thing.
- You’ll have to endure the implied ridicule of people who don’t necessarily know what they’re talking about
Strengths of open stack stack:
- Lots to choose from
- Lots of high-energy young burners know LAMP or RoR or Python or Java from school or hacking
- Hey, if it doesn’t work, you can go fix it! Note that I consider this a bad thing, for startups. (see: Loss of Focus)
- Some platforms just can’t be easily targeted with current MSFT tools (ex: iOS native apps)
Issues with open stack stack:
- Buggy, partially complete releases
- Lack of support
- Fragmentation (for most open-source platforms and tools, the size of the community becomes a key real-world issue)
I don’t think it’s a wash, as in “choose whatever you want, each has their pros and cons.” I’m firmly of the opinion that a MSFT stack results in higher productivity for *most* startups where the skill levels of the developers is the same. That’s partly because Microsoft bootstraps you into a certain minimum set of capabilities just by virtue of using the platform – the “Hello, World” examples on steroids; partly because you have to spend less time debugging and more time working on features customers asked for; and partly because the IDE – Visual Studio – is so ridiculously superpowered (in relative terms) for the average developer, it makes a lot of the day-to-day pain of developing software recede.
Now, like I said, I’m not a zealot. Here are some tools I would *not* recommend for the average startup.
TFS – avoid this like the plague.
VB.NET – avoid this like the plague’s slightly less virulent cousin. Ebola?
Office 365 – Microsoft still hasn’t gotten the hosted business productivity thing down yet. Again, it’s got a V1 or V1.1 feel.
Active Directory – too heavyweight for most startups, whose headcount (and logical POPs within the infrastructure) will number in the ones or tens, not the hundreds or thousands.
What about Azure? I like hosting Windows apps and services on EC2 way better, and having gotten production quality apps out the door on EC2 the advantage Azure brings in terms of simplicity is moot to me, as it should be for most startups after an initial ramp-up period. You’re going to need/want to do things that Azure just can’t provide, or you’re going to want to tweak a knob that Azure doesn’t expose.
What about SQL Server? I like the product, and have developed on it for years, and can sling joins and constraints and correlated subqueries with the best of them. However, I’m sort of ambivalent about SQL Server at the moment; my heart has sort of been stolen by various No-SQL options that force you to give up a lot of sexy, tested, robust things that SQL Server provides in favor of a stripped-down, we-do-one-thing-and-we-do-it-well approach. SimpleDB and S3 come to mind.
One thing I haven’t mentioned is queuing. Queues are a must for cloud-hosted startups, and here’s why: you reduce your need for compute resources at any given point in time by explicitly acknowledging that not everything has to be done RIGHT NOW. Let a dinky little job pull stuff lazily off the queue in seconds, not milliseconds, and for a lot of data sets that’s just fine. For human-scale interactions (i.e. click a page, fill out a form, click a button, go to the next page…) async times are just fine and can save you a boatload of steep OLTP costs. And it sort of forces you to think (or rethink) your architecture in a more detached way, which is a good thing. For non-human-scale interactions, i.e Very Large Sets of Highly Heterogeneous Data, or VLSHHD, queuing also works, because who cares if your carefully constructed report showing Pizza Pocket Sales By Zip Code For February 2012 takes a few minutes longer or a few minutes less. As far as cloud queuing solutions, SQS and Azure Queue Storage both seem about equivalent from a developer’s point of view, and I’ve used both in production code. There are a slew of other upstart candidates that I haven’t looked in to, but redundancy and reliability are key here.
There’s one other thing that I want to mention, and that’s mindset. If you’re a corporate developer used to a Herman Miller chair and a steady paycheck and dental insurance, you may (will probably?) feel anxious and lost when you get into the startup world. That’s not a problem with the MSFT stack, per se. It’s a problem with any corporate devs leave their preferred environment and cast out to sea. I’m sure 20-year IBM vets who have done nothing but REXX or RPG or Java would have the same sorts of adjustment issues. I’m curious to hear how that part of the talk unfolds.
Best of luck to Bryan in his talk next week. I would love to hear your comments.