5 ms·

Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in: - Risking Microsoft's

Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in: - Risking Microsoft's ire by breaking the licenses - Locking yourself in to long-term Microsoft licensing This was a pattern I saw in many, many startups in the 90s -- organizations that relied first on UNIX systems for their servers (often times Solaris, Linux, and in the early-to-mid 90s, IRIX), would eventually adopt Microsoft products for some component of their infrastructure -- usually Exchange, based on heavy political pushes from the growing number of business users. This always to the same effect -- the Microsoft products spread due to lock-in network effects until it began to near 100% MS on the desktop, e-mail, and corporate servers. Production servers generally remained UNIX due to the costs involved. The IT organization shifted to MS, costs went up as the staffing necessarily increased to support administering Windows systems, expensive political maneuvering arose between engineering and business as they both fought to move to systems that they thought better aligned with business priorities. At the end of the day, everyone wound up locked to MS with heavily entrenched political interests in keeping the status quo (and the job security that went with it). Having seen the fall-out from migrations to MS products in corporate IT, I can't imagine voluntarily implementing MS as the primary production and developer system at a startup. You're locking yourself out of alternative solutions, you're signing up for significantly increased capital and operational expenditures, and perhaps most importantly, you're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems.

MrFoof 17y ago
>Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in... There's tremendous value if it's what you already know. The opportunity cost associated with learning and becoming reasonably competent in a different development stack can be non-trivial, especially if you had 5 to 10 years of experience with a different stack or set of technologies. I've yet to encounter a new framework/API/stack/language which I've been able to move to in only a few weeks and be 80%+ as productive as what I already knew, as there's often lots of useful minutiae, subtleties and new concepts you need to acclimatize over time. >You're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems. The converse also applies. Granted, a competent engineer can learn anything, however you're initially inclined to pass on them because of the associated ramp-up time.
- deleted 17y ago
  [deleted]
- tentonova 17y ago
  The opportunity cost associated with learning and becoming reasonably competent in a different development stack can be non-trivial, especially if you had 5 to 10 years of experience with a different stack or set of technologies. I've yet to encounter a new framework/API/stack/language which I've been able to move to in only a few weeks and be 80%+ as productive as what I already knew, as there's often lots of useful minutiae, subtleties and new concepts you need to acclimatize over time. If all you know is Microsoft, then that's all you can do, and the organization's technical direction will almost certainly model that initial decision. However, if you have the luxury of choice -- and I think most people do -- I'd advise against it. The short and long-term costs of Microsoft lock-in are decidedly "non-trivial". The considerable investment in staff, licenses, and technologies make it very difficult to migrate to a non-Microsoft stack in the future. The converse also applies. Granted, a competent engineer can learn anything, however you're initially inclined to pass on them because of the associated ramp-up time. In my experience, you're entirely locking out engineers who use Linux and Mac OS X when you move to a Microsoft stack, but you're not necessarily locking out Windows engineers when you use a cross-platform stack.
  - nkohari 17y ago
    Everyone has the "luxury of choice," but it inevitably comes with cost. I speak from personal experience -- I know the .NET stack very well, and am very familiar with the LAMP stack from my days with PHP, but I've only dabbled in Ruby and Python. Before starting work on our startup, I considered writing it in Rails, but the reality is that it would have taken me much longer to get to market. We hit the market at a very opportune time, and were able to ride a nice wave of buzz to sustainability. If we'd waited another couple of months (my guess at the added overhead of learning Rails), we may have missed our window. The same would naturally apply to someone who already was well-versed in, say, Rails -- it would make no sense to learn .NET unless there was a very compelling reason (say, you were writing a Windows desktop app). Not to mention that the first app you write using any technology you don't understand well is going to suck. If I'm going to base my livelihood on a product, I want it to be as well-written as possible, so I'm going to go with what I'm best at. Also, it's absolutely not true that you're locking out Linux and Mac developers when you write .NET. Some of the best .NET developers I know use a MacBook Pro as their primary machine.
nkohari 17y ago
You're conflating IT infrastructure and software product development, and the two are very different topics. There's literally nothing to stop me from writing .NET software using a Mac (via MonoDevelop or virtualization, like VMWare) and deploying it on Linux (via Mono).
- tentonova 17y ago
  There's nothing wrong with Mono, but neither Mono or MonoDevelop are drop-in replacements for C# and VisualStudio. VMware is not an adequate solution for day-to-day development. There's a performance impact, significant memory overhead, and running Windows inside Linux/Mac OS X is not any more accommodating to users familiar with a UNIX environment than simply running Windows natively.
  - javery 17y ago
    I took some code recently and ran it on Mono and only encountered one issue, which was a Mono bug that has now been fixed. MonoDevelop isn't a drop-in replacement for VisualStudio which is a good thing since VS is bloated and MonoDevelop isn't. I have been writing .NET code exclusively in VMware for 5 years now, 2 years on Windows and 3 years on a Mac. The performance impact is there but it isn't a deal-breaker (especially if you have a fast HDD and enough memory (6GB)).
    - tentonova 17y ago
      I took some code recently and ran it on Mono and only encountered one issue, which was a Mono bug that has now been fixed. MonoDevelop isn't a drop-in replacement for VisualStudio which is a good thing since VS is bloated and MonoDevelop isn't. Confirming neither is a drop-in replacement, which isn't to say that Mono isn't useful or valuable, but simply that it is necessarily 2nd-tier in a Windows-focused development environment. Given that you've spend 3 years developing C# in VMware on a Mac, I'd ask why you're not using native Mono/MonoDevelop entirely? I have been writing .NET code exclusively in VMware for 5 years now, 2 years on Windows and 3 years on a Mac. The performance impact is there but it isn't a deal-breaker (especially if you have a fast HDD and enough memory (6GB)). What do you see as the significant advantage of .NET that has warranted using non-native tools with an admitted performance impact exclusively for 3 years? This sounds like individual developer inertia, not a high-level business decision.
kogir 17y ago
In terms of physical servers, we're actually 50-50 Windows / Linux. Starting on Windows did not blind us to Kannel, Rails, PostGIS, Apache, Samba, Erlang, etc. We use tons of open source software where it makes sense. Sometimes price isn't the only factor when deciding which tools are best for the job. After using C#, switching back to Java or a non-compiled language would be very painful. I'd lose a lot and miss it.
- tentonova 17y ago
  In terms of physical servers, we're actually 50-50 Windows / Linux. Starting on Windows did not blind us to Kannel, Rails, PostGIS, Apache, Samba, Erlang, etc. We use tons of open source software where it makes sense. What do you use for desktops, e-mail, corporate servers, etc? My goal was elucidate the hefty cost of Windows lock-in and Window's demonstrably strong tendency to pervade your organization in terms of political, staffing, and technological investment. If it's considered the best tool for the job and these recognized costs are acceptable, then there's no reason to not use it -- but history should also provide some insight into how Microsoft behaves with organizations that become reliant on their technology. Microsoft isn't being magnanimous with Bizspark -- they're trying to ensure that more startups are locked into their technology stack early, when the perceived immediate advantages may seem most attractive.

MrFoof 17y ago

>Unless the tools/languages are tremendously better than what is available for free/cheaper, I don't particularly understand the value in... There's tremendous value if it's what you already know. The opportunity cost associated with learning and becoming reasonably competent in a different development stack can be non-trivial, especially if you had 5 to 10 years of experience with a different stack or set of technologies. I've yet to encounter a new framework/API/stack/language which I've been able to move to in only a few weeks and be 80%+ as productive as what I already knew, as there's often lots of useful minutiae, subtleties and new concepts you need to acclimatize over time. >You're excluding an entire class of software engineers that primarily work on UNIX-based (including Mac OS X and Linux) systems. The converse also applies. Granted, a competent engineer can learn anything, however you're initially inclined to pass on them because of the associated ramp-up time.

deleted 17y ago
[deleted]
tentonova 17y ago
The opportunity cost associated with learning and becoming reasonably competent in a different development stack can be non-trivial, especially if you had 5 to 10 years of experience with a different stack or set of technologies. I've yet to encounter a new framework/API/stack/language which I've been able to move to in only a few weeks and be 80%+ as productive as what I already knew, as there's often lots of useful minutiae, subtleties and new concepts you need to acclimatize over time. If all you know is Microsoft, then that's all you can do, and the organization's technical direction will almost certainly model that initial decision. However, if you have the luxury of choice -- and I think most people do -- I'd advise against it. The short and long-term costs of Microsoft lock-in are decidedly "non-trivial". The considerable investment in staff, licenses, and technologies make it very difficult to migrate to a non-Microsoft stack in the future. The converse also applies. Granted, a competent engineer can learn anything, however you're initially inclined to pass on them because of the associated ramp-up time. In my experience, you're entirely locking out engineers who use Linux and Mac OS X when you move to a Microsoft stack, but you're not necessarily locking out Windows engineers when you use a cross-platform stack.
- nkohari 17y ago
  Everyone has the "luxury of choice," but it inevitably comes with cost. I speak from personal experience -- I know the .NET stack very well, and am very familiar with the LAMP stack from my days with PHP, but I've only dabbled in Ruby and Python. Before starting work on our startup, I considered writing it in Rails, but the reality is that it would have taken me much longer to get to market. We hit the market at a very opportune time, and were able to ride a nice wave of buzz to sustainability. If we'd waited another couple of months (my guess at the added overhead of learning Rails), we may have missed our window. The same would naturally apply to someone who already was well-versed in, say, Rails -- it would make no sense to learn .NET unless there was a very compelling reason (say, you were writing a Windows desktop app). Not to mention that the first app you write using any technology you don't understand well is going to suck. If I'm going to base my livelihood on a product, I want it to be as well-written as possible, so I'm going to go with what I'm best at. Also, it's absolutely not true that you're locking out Linux and Mac developers when you write .NET. Some of the best .NET developers I know use a MacBook Pro as their primary machine.

nkohari 17y ago

You're conflating IT infrastructure and software product development, and the two are very different topics. There's literally nothing to stop me from writing .NET software using a Mac (via MonoDevelop or virtualization, like VMWare) and deploying it on Linux (via Mono).

tentonova 17y ago
There's nothing wrong with Mono, but neither Mono or MonoDevelop are drop-in replacements for C# and VisualStudio. VMware is not an adequate solution for day-to-day development. There's a performance impact, significant memory overhead, and running Windows inside Linux/Mac OS X is not any more accommodating to users familiar with a UNIX environment than simply running Windows natively.
- javery 17y ago
  I took some code recently and ran it on Mono and only encountered one issue, which was a Mono bug that has now been fixed. MonoDevelop isn't a drop-in replacement for VisualStudio which is a good thing since VS is bloated and MonoDevelop isn't. I have been writing .NET code exclusively in VMware for 5 years now, 2 years on Windows and 3 years on a Mac. The performance impact is there but it isn't a deal-breaker (especially if you have a fast HDD and enough memory (6GB)).
  - tentonova 17y ago
    I took some code recently and ran it on Mono and only encountered one issue, which was a Mono bug that has now been fixed. MonoDevelop isn't a drop-in replacement for VisualStudio which is a good thing since VS is bloated and MonoDevelop isn't. Confirming neither is a drop-in replacement, which isn't to say that Mono isn't useful or valuable, but simply that it is necessarily 2nd-tier in a Windows-focused development environment. Given that you've spend 3 years developing C# in VMware on a Mac, I'd ask why you're not using native Mono/MonoDevelop entirely? I have been writing .NET code exclusively in VMware for 5 years now, 2 years on Windows and 3 years on a Mac. The performance impact is there but it isn't a deal-breaker (especially if you have a fast HDD and enough memory (6GB)). What do you see as the significant advantage of .NET that has warranted using non-native tools with an admitted performance impact exclusively for 3 years? This sounds like individual developer inertia, not a high-level business decision.

kogir 17y ago

In terms of physical servers, we're actually 50-50 Windows / Linux. Starting on Windows did not blind us to Kannel, Rails, PostGIS, Apache, Samba, Erlang, etc. We use tons of open source software where it makes sense. Sometimes price isn't the only factor when deciding which tools are best for the job. After using C#, switching back to Java or a non-compiled language would be very painful. I'd lose a lot and miss it.

tentonova 17y ago
In terms of physical servers, we're actually 50-50 Windows / Linux. Starting on Windows did not blind us to Kannel, Rails, PostGIS, Apache, Samba, Erlang, etc. We use tons of open source software where it makes sense. What do you use for desktops, e-mail, corporate servers, etc? My goal was elucidate the hefty cost of Windows lock-in and Window's demonstrably strong tendency to pervade your organization in terms of political, staffing, and technological investment. If it's considered the best tool for the job and these recognized costs are acceptable, then there's no reason to not use it -- but history should also provide some insight into how Microsoft behaves with organizations that become reliant on their technology. Microsoft isn't being magnanimous with Bizspark -- they're trying to ensure that more startups are locked into their technology stack early, when the perceived immediate advantages may seem most attractive.