Slashdot Mirror
What is Open Source?
s390 writes "The Inquirer is running an article by Olliance about "What is Open Source?" It appears to be the first of a two-part series for managers about how to engage with the open source community. The writers seem to know their material. Are they on target or have they missed something important? Do PHBs really need to read this sort of introduction to get comfortable with the idea of using Linux and other open source software?"
everyone seems to think just because something is Open Source it is default GPL'ed.
Antitrust kind of fell into this trap (worst computer movie ever!).
A friend of mine who works at an unnamed Swedish company was very much for open source software, but when his managers were thinking of buying software they allways went for the medium-small sized companies reather than the large sized or open-source. The reason was that if they programs didn't work purfectly they could put pressure for the companies to fix it. If they refused they would bury them in legal threats and colapse the company and move on. Thus not many companies would refuse to fix bugs and solve problems.
Interestingly the concept of the company fixing its own problems as they hold the source was just unthinkable. No manager would give themselves more work no matter how much money it would save.
Mouse powered Chips, Open source Processors and Lego
That's an interesting point that many people overlook - just because IBM supports Linux doesn't mean that IBM makes a good partner for smaller businesses.
A couple years ago I was part of a vendor selection process for a WMS, and one the three contenders (EXE) basically eliminated themselves by not demonstrating that they took customers of our size (~$200 million) seriously. I sent them data to use for our scripted demo weeks in advance of our visit, only to have their technical sales rep get back to my voice mail with initial questions at 5:30 p.m. the day before we were to arrive - and by that point I was already on the plane. The demo, obviously, turned out underwhelming.
Their functionality was top-notch, but all the signs were that we'd be a small-ish customer to them, and hence not worthy of focused attention (read: flunky implementation consultants among other issues). A major component of any software purchase decision has to be the potential relationship between the customer and vendor, and how well the customer feels they'll be treated going forward...
Stop by my site where I write about ERP systems & more
The only reason big companies will be responsive to requests is if the company doing the requesting is also big (i.e. a very important client). This makes perfect business sense: It is much more important to make sure a client that spends $10 million on your products each year is happy versus a researcher at a university that spends $1 thousand.
Your other point about companies fixing bugs in OSS since they have access to the code is also right on. It is not always easy to fix bugs in code, especially if the code is non-trivial in size or complexity. It takes time to learn the code well-enough to solve bugs in it, unless they are glaringly obvious. So the time that may be saved by reusing open source code must be weighed against the time it takes to learn that code if a company intends to make fixes to it.
Finally, I think most companies do not understand open source licenses, and because of this ignorance, they are afraid that by using open source code they will have to give away all their proprietary code. The threat of this alone is enough to make any company afraid.
At the company I work at, open source proponents would need to convince the high ups at the company (CEO, CIO, etc.) about the safety and utility of open source, and once those guys made a decision to use it, they would make it a possibility for group managers and individual developers to explore open source solutions to use in their projects.
Peaceful regards,
Devin
Only some of the time. One big problem with open source software is that there's only so much attention to go around. High-profile projects like the Linux kernel and Apache get that attention. But once you get past the top 25 projects or so, attention is limited and quality becomes spotty.
The biggest problem is mid-level open source software that's useful but contains some major design error. It's almost impossible to fix such things. Those projects don't get the attention needed for a major rewrite, and the "patch" approach doesn't generate a redesign.
CVS is a good example of this. It's a basically good idea, implemented badly. CVS is a client/server system with a database back end. But the client/server system is ad-hoc, as is the database system. CVS clients look for specific text messages coming back from the server; there's no proper client/server protocol, not even error codes. The "database system" is just a collection of data files, lock files, and status files, which can get out of sync.
"Subversion" was written to deal with these issues. When it's done, it will do about what CVS does, but hopefully better. That indicates a failure of the patch-based open source process. CVS couldn't be fixed within the process; it was necessary to start a new project and rewrite.
Below the projects that are marginally successful is the dark underside of open source, the thousands of dead and moribund projects on SourceForge. The SourceForge people like to boast about how many projects they have, but for most of them, they're just providing free hosting for trash.