5 ms·

A sizeable chunk of .NET development happens in the corporate/enterprise world. That sort of environment isn't interested in collaboration, open source, etc.--

by acabal 16y ago

A sizeable chunk of .NET development happens in the corporate/enterprise world. That sort of environment isn't interested in collaboration, open source, etc.--they're interested in the guaranteed support the MS stack provides, and the idiot-proof web basics provided by ASP/webforms/MVC. If shit hits the fan in the .NET stack for a big enough corporate project, someone in the office can phone/email MS and get support for their problem. If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do. MS will probably fix it in their next cycle, and the corporate devs won't have to waste their time figuring out the nuts and bolts of the stack to fix the bugs themselves, like in OSS. So I think it's this requirement for enterprise support that keeps MS from accepting OSS patches and locking everyone in--it would be too much work to track, validate, and test 3rd party patches when they can just fix it themselves with their own devs and keep going to sleep on their piles of money surrounded by many beautiful women. Unfortunately this sort of view isn't very compatible with the indie developer ideal, or the ideals the author holds--which might one of the many reasons why you see so much Rails/PHP development in the non-enterprise space.

berntb 16y ago
>> If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do. Oh, please... Over the years, I've personally fixed bugs. And sent in fixes. (Stop complaining -- I promise to send tests too, next time!) If I run into one that I am unable to grok in a reasonable time, there are always job boards and money. Bugs -- not to be confused with full sized features -- are generally not that big a problem in even non-popular open source. You don't have to decompile the damn code!! And you can get bugs fixed without waiting for a new release, next year... maybe.
- acabal 16y ago
  >>Over the years, I've personally fixed bugs. And sent in fixes. (Stop complaining -- I promise to send tests too, next time!) >>If I run into one that I am unable to grok in a reasonable time, there are always job boards and money. That's fine for a smaller shop, or even a medium-sized shop. But when you enter a true corporate behemoth type company, you don't have the option of posting an ad on the 37signals job board and hoping a dev cowboy will show up the very next morning and fix your problem. There's HR hoops to jump through, budgets to watch, schedules to keep, managers and colleagues to keep appeased--that's the kind of red-tape stuff that makes hiring anyone, even a short-term freelancer, enough of a PITA to not bother. And as a corporate dev, you have better things to do than waste time hunting, fixing, merging, and patching a piece of software that should really only be a black-box cog in your greater machine.
  - aarongough 16y ago
    Shouldn't the first rule of writing good software be "nothing is a black box"? At some point something in that box is not going to work how you expect it to, regardless of who makes it.
    - acabal 16y ago
      Too bad most mega-corporations aren't as concerned with writing good software as they are with staying on budget, meeting deadlines, and making money. Not to say the two are mutually exclusive, but BigCorp isn't going to want to pay for your time to learn how Apache's threading model works so that you can beat a race-condition bug in PHP's IMAP library (or whatever).
      - berntb 16y ago
        OK, a reality check. First, threading problems in Apache? That is something you report on a mailing list and it gets fixed fast. It is an actively developed application (-: at least last I looked, lots of years ago :-). Second, I am a consultant that do work for a mega corporation, which builds large systems. At least thousands or developers. I don't know (and am too lazy to Google.) I don't know because I work in a small group of developers and seldom interact with large groups of others. Most other developers I interact with in this mega corp also work in quite small groups. Big groups often seems to consist of small groups. When I run into bugs/limitations in an open source library and write a work around (and send in the fix), the manager of my group in Big Corp is happy with me, since I fixed a problem. (His managers probably only hears from him "I'm happy with that consultant despite his humor and personality, keep him".) Now, all this might be different in the Windows world. But when I was there a bit, ten++ years ago, you could find competent people. (Have I been trolled?)
        acabal 16y ago
        To be clear, the threading example was just something off the top of my head, not an actual real-life example. Though the PHP IMAP library is not thread-safe, so the problem would be fixing that library (or learning the guts of it to work around it in certain cases), not Apache. The point is that the example itself doesn't matter. Finally, all of the big companies I've worked for have been MS shops for the reasons I've stated. Of course not every company is going to be the same. But every one I've worked for wants the MS "guarantee" because they'd rather pay their devs to build their product, not to fix bugs in someone else's software. I'm pretty confused as to why these comments have been downvoted so much. Just because someone else's company uses OSS successfully doesn't invalidate the justifications for using MS that I've experienced.
pohl 16y ago
If shit hits the fan in the .NET stack for a big enough corporate project, someone in the office can phone/email MS and get support for their problem. That's the canard, but it has seldom worked out that way for me. Whenever I've encountered a problem that can be traced to a flaw in their products, the suggestion of calling for support is usually met with riotous laughter. (In other words, everybody says it's a selling-point of their stack, but nobody believes it.) Maybe none of our corporate projects have been "big enough". How big, exactly, does one have to be? Edit: come to think of it, most of the problems I have seen have been things that would go against their lock-in strategies, and maybe that's where the laughter comes from. The solution is always something like waiting for hackers to reverse engineer something like NTLM, or Samba, or WINS, or exchange integration...
- jimbobimbo 16y ago
  ...or start with the official documentation coming from - gasp! - Microsoft: http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).aspx http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).as...
  - pohl 16y ago
    I mean no offense by this (even though your condescending gasp makes me relish the thought of offending you) but you're probably too young to appreciate the requisite historical context. The link you provided is a relatively recent change in posture for the company in question.
- acabal 16y ago
  A company I worked for in the past (MM pageviews a day, you've probably heard of them) was a big MS proponent and an early adopter of some of their new stuff, like--at the time--Silverlight. We had a fairly direct line to someone at MS if something crazy happened. It might not always get fixed right away (a bug that might need to wait for the next cycle), but MS was always on top of what needed fixing. Contrarily, we had one guy working on some OSS stuff in a corner of the office--Apache, PHP, Rails, stuff like that. Whenever he ran into a problem that needed to be solved yesterday, he had to find and call a $100/hour consultant who may or may not even be able to solve the problem, or even guarantee that it would be patched at a later date. That's the big MS selling point.
poet 16y ago
Unfortunately this sort of view isn't very compatible with the indie developer ideal, or the ideals the author holds--which might one of the many reasons why you see so much Rails/PHP development in the non-enterprise space. I'd say a much more likely reason is that the enterprise can't get enough programers to support anything other than the MS stack. The culture at large enterprise simply isn't compatible with the hacker mindset. Banks are a notable exception in my mind, but then again banks have always been fairly agile when it comes to turning a profit. Also, the open source ideal isn't an "indie developer" ideal. Serious systems engineering goes on in the open source community and it produces what often are the technically superior solutions.
city41 16y ago
> If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do. MS will probably fix it in their next cycle You also have the option of paying Microsoft for a QFE (quick fix engineering). With a QFE, the team fixes the bug as an immediate priority and provides you with a patch for it. All QFEs eventually get rolled up into cumulative updates and/or service packs.
- aarongough 16y ago
  So I'm paying to fix a bug in their software that I've already paid for? Call me crazy, but if I have the option of cracking open the stack and having a go at fixing the bug myself I'll do it. At least that way I'm not dependent on anyone else for the fix...
  - city41 16y ago
    Hey I didn't say it's a good option, just that it's an option :) The whole "paying someone to fix their bug" always boggled my mind. But it's the reality of MS and the reality of many of their customers. It works for them, so more power to them. I guess.
  - forensic 16y ago
    How much does it cost you to divert your attention to fixing someone else's bugs? It's all just a question of economic efficiency. Being able to pay for priority bugfixes is efficient.
bl4k 16y ago
Yes. This is what the open source world doesn't understand. You can't just copy a commercial product feature-for-feature, open source it and then scratch your head wondering why it isn't gaining adoption. When a corporate pays for software, they are paying for peace-of-mind and assurance more than the bits that make up the app.
- bphogan 16y ago
  That's true for Office and software packages like Webmail. But if you build a system using Microsoft's tools and you ask for support, they'll tell you that the problem is with your code, not their tools. They'll support issues with your web server, database server, and even your IDE, but when it comes to the code itself, there's no level of support they can truly offer. This is from 10 years of personal experience working in an MS centric organization. I get as much support on my Ruby code from MS as I get for the ASP code I wrote. None. But people up the chain don't get this - they think "if we use the MS stack, we can blame them when something goes wrong." I'll gladly take $200,000 a year from a company so they can feel like they can blame me when their apps don't work. I'll just charge them so many points per issue, have them run some diagnostics tool I send them, and say "you have a problem with your code. Can't help you."
  - jarek 16y ago
    But that's what your post's parents are talking about. Microsoft won't debug your code, but they will respond if you show them a bug in their code (and you've paid for the support accounts).
    - bphogan 16y ago
      I was replying specifically to "When a corporate pays for software, they are paying for peace-of-mind and assurance more than the bits that make up the app." The peace of mind part. And that support contract still hasn't provided a fix for the padded oracle exploit. It'll be "a few weeks yet."

by acabal 16y ago

berntb 16y ago

>> If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do. Oh, please... Over the years, I've personally fixed bugs. And sent in fixes. (Stop complaining -- I promise to send tests too, next time!) If I run into one that I am unable to grok in a reasonable time, there are always job boards and money. Bugs -- not to be confused with full sized features -- are generally not that big a problem in even non-popular open source. You don't have to decompile the damn code!! And you can get bugs fixed without waiting for a new release, next year... maybe.

acabal 16y ago
>>Over the years, I've personally fixed bugs. And sent in fixes. (Stop complaining -- I promise to send tests too, next time!) >>If I run into one that I am unable to grok in a reasonable time, there are always job boards and money. That's fine for a smaller shop, or even a medium-sized shop. But when you enter a true corporate behemoth type company, you don't have the option of posting an ad on the 37signals job board and hoping a dev cowboy will show up the very next morning and fix your problem. There's HR hoops to jump through, budgets to watch, schedules to keep, managers and colleagues to keep appeased--that's the kind of red-tape stuff that makes hiring anyone, even a short-term freelancer, enough of a PITA to not bother. And as a corporate dev, you have better things to do than waste time hunting, fixing, merging, and patching a piece of software that should really only be a black-box cog in your greater machine.
- aarongough 16y ago
  Shouldn't the first rule of writing good software be "nothing is a black box"? At some point something in that box is not going to work how you expect it to, regardless of who makes it.
  - acabal 16y ago
    Too bad most mega-corporations aren't as concerned with writing good software as they are with staying on budget, meeting deadlines, and making money. Not to say the two are mutually exclusive, but BigCorp isn't going to want to pay for your time to learn how Apache's threading model works so that you can beat a race-condition bug in PHP's IMAP library (or whatever).
    - berntb 16y ago
      OK, a reality check. First, threading problems in Apache? That is something you report on a mailing list and it gets fixed fast. It is an actively developed application (-: at least last I looked, lots of years ago :-). Second, I am a consultant that do work for a mega corporation, which builds large systems. At least thousands or developers. I don't know (and am too lazy to Google.) I don't know because I work in a small group of developers and seldom interact with large groups of others. Most other developers I interact with in this mega corp also work in quite small groups. Big groups often seems to consist of small groups. When I run into bugs/limitations in an open source library and write a work around (and send in the fix), the manager of my group in Big Corp is happy with me, since I fixed a problem. (His managers probably only hears from him "I'm happy with that consultant despite his humor and personality, keep him".) Now, all this might be different in the Windows world. But when I was there a bit, ten++ years ago, you could find competent people. (Have I been trolled?)
      - acabal 16y ago
        To be clear, the threading example was just something off the top of my head, not an actual real-life example. Though the PHP IMAP library is not thread-safe, so the problem would be fixing that library (or learning the guts of it to work around it in certain cases), not Apache. The point is that the example itself doesn't matter. Finally, all of the big companies I've worked for have been MS shops for the reasons I've stated. Of course not every company is going to be the same. But every one I've worked for wants the MS "guarantee" because they'd rather pay their devs to build their product, not to fix bugs in someone else's software. I'm pretty confused as to why these comments have been downvoted so much. Just because someone else's company uses OSS successfully doesn't invalidate the justifications for using MS that I've experienced.

pohl 16y ago

If shit hits the fan in the .NET stack for a big enough corporate project, someone in the office can phone/email MS and get support for their problem. That's the canard, but it has seldom worked out that way for me. Whenever I've encountered a problem that can be traced to a flaw in their products, the suggestion of calling for support is usually met with riotous laughter. (In other words, everybody says it's a selling-point of their stack, but nobody believes it.) Maybe none of our corporate projects have been "big enough". How big, exactly, does one have to be? Edit: come to think of it, most of the problems I have seen have been things that would go against their lock-in strategies, and maybe that's where the laughter comes from. The solution is always something like waiting for hackers to reverse engineer something like NTLM, or Samba, or WINS, or exchange integration...

jimbobimbo 16y ago
...or start with the official documentation coming from - gasp! - Microsoft: http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).aspx http://msdn.microsoft.com/en-us/library/dd208104(PROT.10).as...
- pohl 16y ago
  I mean no offense by this (even though your condescending gasp makes me relish the thought of offending you) but you're probably too young to appreciate the requisite historical context. The link you provided is a relatively recent change in posture for the company in question.
acabal 16y ago
A company I worked for in the past (MM pageviews a day, you've probably heard of them) was a big MS proponent and an early adopter of some of their new stuff, like--at the time--Silverlight. We had a fairly direct line to someone at MS if something crazy happened. It might not always get fixed right away (a bug that might need to wait for the next cycle), but MS was always on top of what needed fixing. Contrarily, we had one guy working on some OSS stuff in a corner of the office--Apache, PHP, Rails, stuff like that. Whenever he ran into a problem that needed to be solved yesterday, he had to find and call a $100/hour consultant who may or may not even be able to solve the problem, or even guarantee that it would be patched at a later date. That's the big MS selling point.

poet 16y ago

Unfortunately this sort of view isn't very compatible with the indie developer ideal, or the ideals the author holds--which might one of the many reasons why you see so much Rails/PHP development in the non-enterprise space. I'd say a much more likely reason is that the enterprise can't get enough programers to support anything other than the MS stack. The culture at large enterprise simply isn't compatible with the hacker mindset. Banks are a notable exception in my mind, but then again banks have always been fairly agile when it comes to turning a profit. Also, the open source ideal isn't an "indie developer" ideal. Serious systems engineering goes on in the open source community and it produces what often are the technically superior solutions.

city41 16y ago

> If a bug is found in the stack itself, it won't languish unsolved in bug trackers for years, like many OSS bugs do. MS will probably fix it in their next cycle You also have the option of paying Microsoft for a QFE (quick fix engineering). With a QFE, the team fixes the bug as an immediate priority and provides you with a patch for it. All QFEs eventually get rolled up into cumulative updates and/or service packs.

aarongough 16y ago
So I'm paying to fix a bug in their software that I've already paid for? Call me crazy, but if I have the option of cracking open the stack and having a go at fixing the bug myself I'll do it. At least that way I'm not dependent on anyone else for the fix...
- city41 16y ago
  Hey I didn't say it's a good option, just that it's an option :) The whole "paying someone to fix their bug" always boggled my mind. But it's the reality of MS and the reality of many of their customers. It works for them, so more power to them. I guess.
- forensic 16y ago
  How much does it cost you to divert your attention to fixing someone else's bugs? It's all just a question of economic efficiency. Being able to pay for priority bugfixes is efficient.

bl4k 16y ago

Yes. This is what the open source world doesn't understand. You can't just copy a commercial product feature-for-feature, open source it and then scratch your head wondering why it isn't gaining adoption. When a corporate pays for software, they are paying for peace-of-mind and assurance more than the bits that make up the app.

bphogan 16y ago
That's true for Office and software packages like Webmail. But if you build a system using Microsoft's tools and you ask for support, they'll tell you that the problem is with your code, not their tools. They'll support issues with your web server, database server, and even your IDE, but when it comes to the code itself, there's no level of support they can truly offer. This is from 10 years of personal experience working in an MS centric organization. I get as much support on my Ruby code from MS as I get for the ASP code I wrote. None. But people up the chain don't get this - they think "if we use the MS stack, we can blame them when something goes wrong." I'll gladly take $200,000 a year from a company so they can feel like they can blame me when their apps don't work. I'll just charge them so many points per issue, have them run some diagnostics tool I send them, and say "you have a problem with your code. Can't help you."
- jarek 16y ago
  But that's what your post's parents are talking about. Microsoft won't debug your code, but they will respond if you show them a bug in their code (and you've paid for the support accounts).
  - bphogan 16y ago
    I was replying specifically to "When a corporate pays for software, they are paying for peace-of-mind and assurance more than the bits that make up the app." The peace of mind part. And that support contract still hasn't provided a fix for the padded oracle exploit. It'll be "a few weeks yet."