Slashdot Mirror
Succeeding With Open Source
Implementing an open source solution requires a different approach from the buyer's point of view: There is no salesperson you'll get a call from, there are no license agreements to sign and no serial numbers to enter. Access to the software is simplified, but sometimes there are few pointers about what to do next.
Golden takes the reader through different aspects of dealing with open source technologies. As one can see from the table of contents, the information is presented from the business professional's point of view. This title is for an IT manager, not developers or IT personnel who might be using open source products already and feel strongly about them. The basic question that the book explores is this: When does it make sense for an organization to implement an open source product? How do you evaluate the product's maturity, functionality, ease of use, support infrastructure and documentation quality so that running open source within the organization starts making sense?
Golden's answer is the Open Source Maturity Model (OSMM), which the author developed himself. The model asks the IT manager to evaluate the software, support, training options, documentation, integration and professional services on 10-point scale. If the technology ranking reaches a certain score (which highly depends on the userbase), then it will make sense to implement it.
For example, on page 144, when the author discusses software support options, he suggests assigning 6 points for excellent community support, 3 points for available paid support and 1 point for availability of self-support (i.e., an employee who understands the product). So on the next page JBoss gets 6 points for community support (very helpful and respectful forums), 2 points for commercial support (since it was e-mail and phone only, and no on-site support) and 0 points for self-support (since no one within the organization stepped up to claim herself as JBoss expert).
JBoss is the prime example used by the author throughout the chapters, and turns out to be quite a convenient choice -- the company offers commercial support, training and documentation for an open-source product. Golden's model is supposed to help IT managers distinguish high-quality open source projects from 0.0.1 version, so widely available on SourceForge.
The book's primary market is business professionals and IT managers who would probably benefit from having a formal evaluation model instead of relying on pure gut feeling. Despite the book's ambiguous title, it's not a manual on how to create your own business with open-source products. Some chapters will be helpful for figuring that out (Chapter 2 talks about business models in the open source world), but it's mostly for people who are implementing rather than developing open source products. The language is somewhat dry, but if your weekly reading requires CIO Magazine, you're probably used to that.
Something I think the author would have done well to include is a collection of in-depth case studies on open source implementations. There's some data on Sabre and Charles Schwab running successful businesses on open-source infrastructure, but the details are not there. While certain companies publish hundreds of case studies to prove that their products will either save money or allow the customer to make more, the success stories are not that frequently publicized in the open source world. Having such material in the book would provide a confidence booster for an IT manager, I think.
The last chapter or the first appendix is where I would expect to find information on solid open-source products suitable for corporate deployment. I mean, if the evaluation model is introduced, why not list the most prominent projects out there for quick reference? The highest-ranked open-source operating system, office suite, corporate messaging system, accounting and tax package, etc.?
Overall the book is pretty good for a manager who has heard of open source, but has not read too much into it. Chapter 1 in PDF format is available from Addison Wesley site. Golden also wrote an article for OreillyNet that deals with bringing open source into the organization. There's also an interview with the author on TechTarget.
You can purchase Succeeding With Open Source from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I think that the efforts of many big companies to introduce Linux into the corporate world in the past couple of years and the years to come, are, while greatly appreciated by most OSS developers, could be harmful in the long run to OSS in general. It's no question that every OSS fanatic wants nothing more than to see OSS on everyone's server and home computer, and lately a lot of companies have expressed similar interests. I think, however, that the motives should be questioned here. The motives of OSS developers are quite clear to most, and the motives of large corporations are clear to most as well. And anyone can see that, though joined by the desire to have more secure and publicly avialable software, the two ideological motives are on the opposite ends of the spectrum. The corporate interests are always clearly monetary, and that has always proved to harm anything it comes in contact with. While the GPL, and a slew of other licenses and agreements is there to protect open source, there will be many more cases like SCO if open source fully enters the corporate playground. Let's hope at least that the people at IBM, Novell and Sun understand what "the spirit" of Open Source is about and act with respect.
First, Open Source or Free Software is not alone about free access to the source, it's also about helping each other. Even when in commercial settings this is not an option in all aspects, it can still help.
For example there is the Open Source Observatory -- when you do not trust OS zealots, you may trust more independent sources. There are documents (like the Open Source Migration Guidelines), case studies and events where you may meet others with similar questions.
In short: look around and get a clue. Helps enormously and makes much more things better than just software.
That assumes that the proprietary stuff will do what you want. In a case where both the open source and proprietary solutions are close to what you need but not exactly right, you've got a much better chance of being able to adjust the open source one to be a perfect fit.
From the sounds of it, it doesn't look like the book really tackles comparing proprietary to open source solutions; even though its ranking system could be just as well applied to the proprietary stuff.
Sometimes it is better to speak the same language of those who take the decisions. It is a sad when a good initiative is dismissed because the people pushing it were not able to communicate it property to the management.
I suppose in theory, but it's often beyond the bounds of the practical. Sometimes apps make assumptions that get so deeply ingrained that it's nigh impossible to root them out (or at least it becomes seemingly easier writing the whole miserable thing from scratch).
Two points:
1. That was lame and completely not funny.
2. The whole "??? - Profit!" line is poking fun about the lack of a business plan with most Internet companies in the mid-to-late 90s.
However, in your comment, you are referring to selling books. Step 3 would read "3. Sell the book." There is nothing "new media" about book sales. It is an old industry with time-tested methods.
-- Fighting mediocrity one bad post at a time.
You forgot the absolutely most common open source project category:
5. New software currently being developed by one programmer without backing from anyone.
This is by far the largest category. Often this one programmer has rather interesting ideas about user interface and the requirements of the user community toward which he is targeting the project. And, yes, "interesting" is meant in exactly the same way as the Chinese curse "may you live in interesting times."
A better question to ask is: "What provides the best solution to this problem?". If open source provides the best option, great, go with it. If being open source itself provides a solution to a problem, say making sure that the software can be updated in house, for example, that's a different story. In real life, you pick the best tool for the job. Sometimes that means commercial products, other times it doesn't.
RandomAndInteresting.comdefending the world from stupidity since 1979
"Open source is great, but where do we get support?".
Seriously - for the project I'm on now the client has insisted we use Weblogic, even though all we're using is the servlet container. Resin or tomcat would have done the job just as well for a fraction of the cost, but they want the big-name backing and support contract.
(Yes, I realise that that's often a false sense of security - don't tell me, tell the client.)
It's official. Most of you are morons.
But you forget how /. mods work:
1) Post any comment with 'Profit!', 'I for one welcome our new ______ overlords', or 'In Soviet Russia, _____ ______'s you!' in it.
2) ????
3) +5 Funny!
in bed.