Hacker News new | past | comments | ask | show | jobs | submit login

>> 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.




>>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.


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.


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).


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?)


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.


If you're not trolling me and are generally confused, here is where I'm coming from.

I think the confusion is that I work for a big corp that do software as a central part of their business -- I'm not writing applications with shiny buttons on administrative applications (desktop or web) ordered by monkeys in suits.

I'm here to write lots of functionality and teach people. For that, we use scripting, open systems that are flexible -- and pluggable. I can always change what I plug in, with the limitation of having to teach people.

If it was the best solution, we would e.g. add a Windows machine and script Excel. The main problem would be that stuff in Microsoft applications tend to work badly in the next version and it is a f-ing pain and waste of money to rewrite stuff you implemented well a couple of years ago.

(Lots of other people here work as army ants on big projects where they should be replaceable. They use Java or C++, deploying little to Windows. I do server apps, not embeddable here, since I love the speed of creating functionality with Lisp, scripting languages etc.)


>>To be clear, the threading example was just something off the top of my head,

That is OK, since I just skimmed the example and saw problems with Apache/PHP std lib.

It was just stupid. Lots of people use those -- and bugs are killed fast.

In absolute worst case, use an external program in another language for this. (Processes or threads doesn't matter.)

That works, since IMAP4 was new and shiny in the mid 90s(!) -- in the non-MS world, we don't replace functioning standards all the time so there are multiple implementations out there for e.g. email libs...

>>I'm pretty confused as to why these comments have been downvoted so much.

Because you only know one side of things -- and believe the propaganda about the other side.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: