in reply to Criterion for success in open source

I think you're all right. Yes, it could be much better. Is it broken? No! It's amazing how well these bears dance! The tools you speak of in your follow-up attest to the enormous creativity of the OS movement. Compare this with trying to fix an incompatibility between M$ and Symantec... MTBFix is about five years, maybe, if ever. Remember "We'll fix it in five oh"???

Another point to be made is that the very nature of open source is that the wheels usually *have* been invented before (yes, it's a good thing!), and the info is out there. One of my cow-onks had some common code that built input multiplexing daemons, and we discovered that his code was linking to the wrong library APIs when we used it in two different daemons at the same time... a little research and he discovered "versioned symbols," invented to solve the glibc version crashes that plagued the GNU and Linux worlds for several years.

I think the real issue is not that there's a lot of chaff out there, it's separating the wheat from the chaff. There are two answers to this: know what you're doing, and know whose code you're running. One could postulate rating systems like PM's XP for projects -- and, yes, they're out there -- but there is no substitute for grokking something until you understand it. If you're in bed with somebody else's code, don't blame me if you get AIDS. :D

Don Wilde
"There's more than one level to any answer."
  • Comment on Re: Criterion for success in open source