Stokey asks:
"I work for a global finance firm, (60000+ employees and presence in 25+ countries) in the Group IT department. Pressure is building from the businesses to cut costs and Open Source software has been pushed onto the discussion table. I am trying to educate IT Directors where I can with correct definitions, breaking down assumptions, and will most likely end up writing the group wide Open Source policy. The challenges are well known: risk, cost, support, licensing, benefits, training, and so forth. I am looking for help in putting together a pack that can be handed to our IT Directors forum which contains a policy, TCO (Total Cost of Ownership) reviews, and risk reviews by companies that have done it. After asking what Gartner has to say, the next question will be 'So who else has done this?'. Can Slashdot assist?" What information do you think should be included to sell Open Source to management at the top-level of any corporation or business?
I'm sure several of you have run into this situation before, so I figure this may be as good of a place as any to suggest what information might be appropriate to place in such a policy, especially for future IT workers who find themselves in this position. If people are serious in getting Open Source further into the enterprise than it has already is, such information will be necessary to convince the powers-that-be on the things that we already know: Open Source can be as good as, or better than, commercial software for business tasks. Things like licensing descriptions, common misconceptions, and what Open Source really is would be an absolute must. What other information do you think would be absolutely necessary to include into such policy?
Slashdot Mirror
Some open source projects are very well done, and provide clear and immediate benefits upon implementation - assuming that you have problems that they solve. Others are less so. In other words, don't try to sell "Open Source" as a fundamental concept. Sell specific open-source solutions to specific corporate problems.
Remember also that everything is relative. Let's say that you're working for a small software company. You need an office suite. You could use OpenOffice, which has no initial cost and a small but non-zero chance of incorrectly storing documents that get sent to potential customers and investors. Or you could go to Microsoft.com and get a ton of NFD software, including Office, for a couple of hundred bucks. Here, the open-source solution fails to be appealing. If you're developing J2EE applications and need a good app server though, its very possible that JBoss provides a compelling open-source alternative to expensive software like WebSphere.
But (and here I'm speaking as the CTO for a growing software company), if you start out with blanket statements like "Open source has lower TCO," without talking to the specific context of a business problem - I may agree in principle, but speaking as the company, "I don't care." Solve a problem, do it well, do it cheaply, and you'll find that the company execs don't care either - but that holds true in both directions. If the best solution happens to be open-source then they'll probably go for it, but not because its "k3wl" or open, but because its better for the business.
This is the time for open source to, as they say, put its cards on the table. The advocates feel that it does deliver lower TCO (and other advantages). I happen to lean that way myself. But that should mean, ironically enough, that the end product should be superior without including the specific point that its open source, any more than I would pick any other product because of the way that its built. The better building technique produces a better product, and that's why it gets used.
At least, that's my opinion.
You're special forces then? That's great! I just love your olympics!
It sounds like you may need to talk with IBM (or other large open source based company, maybe RedHat? ) about some of this stuff -- they probably have done a lot of the homework for you.
Good luck, please let us know how this goes!
"To make a mistake is only human; to persist in a mistake is idiotic." Cicero
Try digging back to as far as the 70's and 80's when companies hired people to write them code. The idea of relying on closed-source software was really an idea from the late 80's and 90's, sold on the idea that it would be cheaper.
If a large company commits to integrating some Open Source, hire programmers to "tweak it the way they want" and then contribute the resulting code back to the Open Source community.
THEN compare your TCO's, RTI's and EIEIO's to you CICIO's.
Ruby on Rails Screencast
The Robert Francis Group has a .pdf of a study commissioned by IBM on the TCO of Linux (the link is for web servers, but there are other .pdf's under the 'research' link). You have to fill out some data, but it doesn't have to be representative of you. Download the PDF, it's pretty interesting!
"History doesn't repeat itself, but it does rhyme." Mark Twain
Verizon's IT division had been running the entire development team on Linux, Openoffice for years now. There was an article somtimes back, on newsweek about a Verizon Director George Huges's initiatives.
Nobody expects the Spanish inquisition....
Another fine article - EU Publishes Open Source Migration Guidelines
Interesting read.. Your biggest opponents are going to be your non-coding macro writers...
-B
Try Caterpillar for a real life example! -- I know personally that all their back end servers and mission critical servers are indeed open source.
/. here
And - NASA's going open source too see
All Your Base Are Belong To Us
>>no, they are saying "I don't trust that a non-
>>commercial entity can provide ongoing support
>>nor do I trust a product without several names >>I can immediately call to get my request routed
>>to the correct division for support"
Do you of many non-commercial entities that trade publically? Going open source doesn't mean you're going non-commercial. It means you have the option to go this route, or not go this route.
Wow, we can use all this great software we found on Sourceforge for our corporate enterprise. Then when it's abandoned like so many projects are on sourceforge... what? Oh great, we can 'read the code'. What do we do now? We can either wait for some bored group of kind souls to take it over, or we now have to hire ourselves a permanent staff of 50 code monkeys to keep the code patched and updated? Great. That's going to do wonders for the bottom line.
Having access to the "source" does you no good unless you are personally going to set up the staff up to make use of that fact. Ford motor company doesn't want to spend millions and millions of dollars maintaining their own operating system for use inhouse. They pay some company to provide the OS and share the costs involved with tens of thousands of other companies that also want to buy that software.
Seeing #includes is nice, but having a company standing behind and maintaining the software is what is needed.
I also work at a financial services company. Our Policy:
If the open source is supported by a company, then we can sue the company, and it's okay to use it.
On the other hand, we use Perl extensively (though not as extensively as I might hope) and though we officially get our modules from an ActiveState CD, we do have modules from CPAN, though ones I've tested well.
I used to work at a company that had an exceptionally good policy.
I'd like to expand on theirs and propose one that is like this:
1. Open Source software is to be considered equally with closed source software when it comes to product features.
2. Support for open source products should be considered alongside support options for closed source products and both purchase and support costs counted into the total cost of purchase / ownership.
3. Small one-off and/or utility products should not be required to be supported by a vendor. This means primarily code and products that are easily understood and thus where support for them in-house is not difficult or problematic.
4. Any time a large open-source product is considered, such as Apache, MySQL, Linux, etc., some investigation should be made of viable support options along with the true cost of in-house support (learning curve short or steep, etc.)
5. Large support vendors (PC desktop support companies) should be encouraged / required to provide support for open source desktop applications such as MySQL admin tools, etc.
6. Internal projects whose functions are not firm-specific should be strongly considered for placement in an open source mode.
7. Attention should be paid in the design of all projects to move proprietary or business-specific information from source code into configuration files. This will enable easier decision making about making a project open source.
8. Projects that are designated by a manager as open source should be hosted in a publically accessible location such as SourceForge.
9. One project lead should be designated (usually the project manager, but it may be the chief technical person). This person should be responsible for filtering all proprietary information out of the code and documents placed in the open source repository.
10. A project homepage and some documentation should be created for the open source repository. This should also include release notes and postings on FreshMeat.org on a semi-regular basis. The dual goals of the publicity should be to encourage others to use the software and thus contribute to the development / support of it. This should include the web-search-ability of the project to make sure anyone searching for it will be able to find it.
Unitarian Church: Freethinkers Congregate!
OpenOffice.org's presentation software "Impress" can open and save PowerPoint files:
From http://www.openoffice.org/product/impress.html
"Of course, you are free to use your old Microsoft PowerPoint presentations, or save your work in PowerPoint format for sending to people who are still locked into Microsoft products. Alternatively, use IMPRESS's built-in ability to create Flash (.swf) versions of your presentations."
$8.95/mo web hosting
Hope those references help.
- David A. Wheeler (see my Secure Programming HOWTO)
That said, many development managers and architecture folks have seen value in open source for some time, and have utilized it in projects (below the radar). As the quality of open source increases, and the deliverable become larger (Xerces to OopenOffice), we asked that the company formalize the usage of OSS.
During discussions we argued that OSS should not be treated differently than other purchased and/or developed SW. We did see a few exceptions:
However, once those have been met (i.e. the risk issue is mitigated), we saw no difference between vendor code and OSS code.
Legal and Security drafted a policy, and it recently became official. In essence, the policy states the few additional risks that must be mitigated, and then states that OSS must go our normal software acquisition procedures.
I know some purists (zealots...) may disagree with the exceptions above, but we decided they were acceptable, were good business practices (remember, business could care less about the OSS philosphy, they are interested in lowering costs and/or raising quality while not raising unmitigated risk...), and were not worth the fight to remove. We decided this policy would allow us to utilize open source where appropriate, and time will pass. As the fight shifts from components (MSXML versus Xerces) to applications (MSOffice versus OpenOffice et al), business will become more comfortable with OSS, and the policies will change to reflect that (I remember in 1994-6 when companies resisted WWW, because they saw no value in it).
In the end, though, resist the urge to make the policy a political statement. I agree OSS needs help to thrive in a corporate environment, but not that much help. If OSS can't lower prices and/or increase quality while not raising unmitigated risk, then it truly is not appropriate for business.
As for the other items you mentioned, I don't think TCO is best done globally. Quite frankly, in some areas, OSS has lower TCO, in others it does not. Risk can be generally reviewed at the global level, but risk really depends on usage (Writing reports with OOO is low risk, calculating agent commissions with OOO might be high risk).
I agree with others that if you are looking for a "why use OSS", Call IBM or RedHat or some other places, there is plenty of material like that out there. Coupled with Gartner and Giga/Forrester, you should be set.