What is Open Source? 322
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?"
The thing I see is (Score:5, Interesting)
Antitrust kind of fell into this trap (worst computer movie ever!).
GNU's definition (Score:3, Interesting)
Personally, I think its the license, which answers the question.
Quality "Ensurance" (Score:1, Interesting)
Like the authors I'm a Brit so I know the British distinction between 'insure' and 'ensure' but I'd never say 'ensurance', I'd say 'assurance'.
You know, like 'QA'.
Re:Like it or not, managers default to commercial (Score:5, Interesting)
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.
Company-to-Company relationships are important (Score:5, Interesting)
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...
Re:Like it or not, managers default to commercial (Score:4, Interesting)
I find that kind of interesting, if not slimy. Most software includes some type of "provided as-is license". This would seem to indicate that a customer doesn't have a lot of legal ground to stand on regarding buggy software. Custom contract work is probably a different story.
Has anyone actually sued (and won) a vendor for buggy software? I'd be interested because Quicken on the Mac, though far more useful than Gnucash, crashes quite often. Intuit has acknowledged this, but provided no fix. Guess they think I should be grateful they didn't write info to my MBR....
Re:Like it or not, managers default to commercial (Score:4, Interesting)
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
Quality? Not. (Score:5, Interesting)
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.
Eh? (Score:1, Interesting)
Here is the PHB daily priority list:
1) The Lunch Menu
2) What's at Blockbuster on Friday
3) Today's all-day meeting refreshments
Re:Quality? Not. (Score:4, Interesting)
The "dark underside" you refer to exists regardless of the development model. I can't tell you how many projects I've worked on in the "real" (read "commercial") world that went exactly nowhere. The difference, of course, is that these "real" projects (and, occaisionally, a career or two) would die a quiet death in a shallow grave in a cubicle, rather than in public on freshmeat.
IMHO, the mortality rate for OS projects is just about right. And try not to think of failed projects as "trash". Think of it as rich loam, the vital compost that will spawn new (and possibly) better OS software. Or not ;)
Re:Open Source (Score:2, Interesting)
If you make something good for an MS platform, you'll end up competing with them unless your bought out. Every MS internally started venture (excluding Directx) has failed. MS has a tendency to buy the cleap clones and attempt to rewrite history.
Re:Company-to-Company relationships are important (Score:2, Interesting)
Re:Open Source (Score:2, Interesting)
Just try to use MS academic licenced compilers and you will understand the difference. With open source you get to see and learn how base c libraries really work. Far better for learning than the hidden binaries necessary for closed source computing.
Even the Microserfs use open source to learn how things work. Working for Microsoft is like working for the CIA, you are only allowed to see the source segments you are working on.
Bold claims (Score:3, Interesting)
From the article:
Open Source software solutions exist for virtually all types of business applications.
Don't get me wrong. I am a very big proponent of Open Source software. Not only do I think it is a good idea, I honestly think that it is very good for humanity as a whole. My only problem is that that statement is somewhat misleading.
While the basic office application suite is just reaching a maturity level where it can be plausibly considered a viable solution, business applications consist of a lot more than that, and often include very specialized industry-specific niche software. A PHB is going to read that statement, look at whoever handed them the article (it must be printed for the PHB to read it, so all this is happening in meatspace), and ask them if there is an open source version of the real estate accounting software they use. Those of us who have seen such software will immediately realize that we are not talking about a speadsheet, nor a Quicken clone, but a very complex and full featured accounting package some oddball company with no competition writes for that particular industry. It will be buggy, bloated, and incredibly expensive, but it is often the only tool to do certain things that particular business needs.
Furthermore, there are certian generalized types of business software, most notably document management, groupware, and workflow that don't (to my knowledge) have effective open source solutions. (Part of the reason I am risking a troll mod in writing this is to find out that I am wrong, so if you know something I don't, please reply!)
The way I see it, the Open Source approach to these sorts of problems is to put the problem solver closer to the problem. Rather than pay $80000 to some screwy outfit in Nevada who happens to write the world's only accounting and office managment package for veterinarians, you hook up with the local Linux guru who knows something about PHP, MySQL, etc. and have him develop a database solution. This leverages the flexibility and power of Open Source software and results in a fairer and more responsible arragement between the providers and consumers of technology services.
If that business model is what we are all about (as Open Source people), don't we need to sell that idea to PHBs?
Re:Like it or not, managers default to commercial (Score:3, Interesting)
I was going to point out that reliable, accountable support is available for many open-source software packages too, from vendors ranging from IBM and RedHat down to the self-employed geek down the street that runs his own consulting business, but I realized you had a point.
When a commercial support organization for an open-source application gets a bug report, they can analyze the source code to gain an understanding of the app design, troubleshoot to the best of their understanding, and consult the original authors via mailing lists or whatever about the things they can't understand themselves (and the authors have no obligation to respond, since they're not getting paid to). If the support company does not provide good support, they lose the support contract.
When the support org of a proprietary software company gets a bug report, they have vast amounts of internal resources available to help them understand, troubleshoot, and correct the error. Many of the people who originally developed the application are likely to still be employed by the company, obligating them to share what they know. If the software company does not provide good support, they lose the support contract -- AND lose out on future sales of their product.
Ultimately, source code alone is NOT sufficient documentation to support an application. In order to understand how something works, you need the project specs, design docs, etc. -- and very few OSS projects provide that kind of documentation with their source. On the other hand, most commercial developers are required by company policy to create such documentation.
Re:Missing the Point (Score:3, Interesting)
Pro/E of course will eventually run on Linux [ptc.com],
One problem is the GM IS&S directorate that no open source software shell be used. This came, interestingly enough, right after they began to move to Windows platforms for Unigraphics. More interesting is that their servers all run HP-UX, and that they integrate with their existing Win2K DFS system using CIFS 9000. Hmmm...no open source, huh? (For the uninitiated -- CIFS 9000 is just Samba relabelled by HP)
Ah well. I did the best I could to advocate Open Source while I was there and was told to just 'drink the kool-aid.' *sigh*
Re:One misconception I had (Score:3, Interesting)
Having gone and taken a look at your Open Source Music License" [rootrecords.org], I disagree with your definition of what "source" means as pertaining to music.
The way I see it, any audio recording of a piece of music IS the end product. It's a performance of the 'source', which is the words and notes that comprise the music itself.
Even copyright law makes a similar distinction -- the copyright of a song pertains to the chords, lyrics, printed sheet music of a song; the phonographic copyright pertains to recordings of the song. If you make a copy of an audio recording, you must get permission from the phonographic copyright holder; if you record a song yourself that was written by someone else, you must get permission from the other kind of copyright holder (under US Copyright Law there are conditions where licensing is compulsory, but I digress).
My conception of a GPL-like music license would be one where artists could sell CD's containing recordings of their music. They would not have to allow people to make their own copies of the CD's, but they WOULD have to provide 'source code' for their music (as lyric files, sheet music, MIDI, or some other conceptual representation) and allow people to make their own recordings of the music, provided the orchestration/interpretation/whatever changes were documented in the 'source' and distributed along with the rerecordings.
There are at least a dozen different open music licenses listed on the EFF site, I bet at least one of them contains exactly what I've described. But it does demonstrate a concern about open-source movements -- what is the most appropriate way to apply computer programming concepts like 'source', 'binary', and 'compile' to fields that are not computer programming?