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.
Having been installing and supporting MS products for a very long time, I would say that there is considerable risk in sticking with them. Over the past 10-15 years many enforced upgrades (to newer versions of office products for example) have required significant rewrites and porting efforts (the horrors of upgrading Access through several versions are well known). Open Source and Open Standards bring security and stability.
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)
The trick with the desktop is that you lock it down as far as you can so that each user can do just what they need and no more (you should be doing this with Windows anyhow ;). There's not many calls saying "How do I use X to do Y" because the user can't even see X in the first place.
This takes care of call cent(re|er) staff, and indeed almost anyone whose job involves little more than accessing a system through a terminal or web browser. It also makes the client much easier to handle because all you have is:
- Base Linux Install
- X Windows
- Terminal Emulator
- Mozilla
The complicated bit is anything which requires a fancy Windows program for which no replacement exists. Here you've two main options: rewrite it (either yourself or pay a 3rd party) or use Citrix.The way you sell this, as has been discussed before, is in terms of cost-risk-benefit. In the above example, the biggest change is to the client PC, which probably doesn't do much business-critical stuff anyway and so you're rather less bothered than you might be at the server side.
This fascination with making KDE look as much like Windows as possible, including aping the colour scheme and button design right down to the nearest pixel, just to say "It looks like Windows so it must be as easy to use!" is, IMHO, a load of rubbish. 95% of Windows "ease of use" is marketing.
Unfortunately it's very good marketing, but that's not the point here...
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.
So what you are basically saying is that you risk your job by violating corporate policy, because you have a huge boner for Linux and are completly anti-Microsoft? Christ, dude, I won't feel sorry for you when you get in trouble for running Linux.
I probably shouldn't feed this troll, but here I go anyway.
You are looking at it from the wrong perspective. I don't care that it's linux, windows, freeBSD, macOS, or whatever that's on my desktop. Although windows is what is 'officially' supposed to be on my system, I found it not to be the most productive and stable development environment for what I do.
You probably can't understand this because you either aren't a developer, or have not done 15 years of *nix-based development like I have. The environment and tools available in *nix systems for developers are impossible to beat for those that know them. Cygwin and such helps, but it isn't the same thing and you spend more time fighting to get the tools to work right than you do using them, although the gap is closing.
There is really no risk to my job. The management chain up to my VP knows I run linux, and a few other people around here run it too. A good boss supports an environment where developers can use whatever tools and such that are the most productive for them, regardless of the corporate standards. And since my work revolves around Java development, there's a good chance that the official tools will even run fine.
Overall, since we target and run everything on big-iron *nix systems anyway, those of us that develop on Linux find it easier to deploy and work in an environment that more closely matches that of production.
I think you'll find this has nothing to do with bigotry. In fact, I used to run nothing but FreeBSD, however found it to be lacking in terms of Java tool support, while everyone supports Linux these days.
This post is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
- Someone who knows the product - really knows the product - can fix it faster than the in house geek.
- This is a variation on the first point, but there is a good chance that someone else has already seen the same problem or a similar problem. If everyone contacts a single source (the vendor), there's a good chance (if the vendor is any good) that someone either knows how to fix the problem and/or that the vendor has a fix/patch. I know I, like most of our gentle readers, google quite frequently to see who has had the same problem I'm having with, say, Linux, and what they did to fix it. But what if its (a) an obscure problem or (b) the other person didn't feel like posting his/her fix (I know I'm not alone in finding 10 people who have posted "I'm having problems with X" with no replies or solutions. You know that there is probably a fix out there, but you can't find it. Woo hoo - reinvent the wheel time!)
- We're already short on people; vendor contracts hit our budget differently. My company - based on what the business has said "you must do this year" - is 100 PEOPLE short. They're hiring for some of the projects (but the projects are going to be automatically behind due to ramp up time); they're postponing other projects; and they're using contractors for other projects (which comes with its own set of management headaches) To support software would mean you'd need someone on staff, pay their salaries and benefits, and schedule them in such a way that they're "available" if something goes wrong (which means you use them the rest of the time how?).
Look at a support contract as an insurance contract - you're paying someone else to make sure things work. And you're paying them to keep the staff (claims adjusters, to carry my pathetic analogy) available so that if you do have a problem the problem is fixed quickly.Interesting read: http://www2.cio.com/consultant/report2214.html
They suggest a policy dividing OSS in three tiers where tier one applications would include Apache, and Linux. These are apps with substantial commercial backing and professional support offers. These apps can be used with relatively small risk.
Tier two apps include Mozilla or MySQL. They have commercial support but are less wide-spread. Depending on your own policy/risk-taking-ability you can decide to use these apps or only allow them for internal or development purposes.
Tier three applications include all the rest. They might be great, but it will be hard or impossible to get support and they might be unmaintained. For internal/development use only.
They also give a lot of other information about OSS policies.
I work for a non-profit org called The STAR Center. We made the switch to Linux nearly 5 years ago. Here's a NewsForge article that Jacqueline Emigh wrote about us a little over two years ago. We've since switched most of our servers to FreeBSD, but OSS is still the way to go.
TCO issues can be addressed in this manner. You have to have hardware either way. You have to have staff either way. The difference is that you can have as many servers and workstations as you need to support your user base, but there are no licensing fees or upgrade fees. True enough, you will probably expend a nontrivial amount of staff resources in migrating from Windows to Linux, but no more than you'd expend in migrating from Linux to Windows.
The other thing you need to keep in mind is that you don't have to be in any rush to do your migration. It's been five years since we migrated our server functions to Linux, but our workstations are still running Win98. Our ultimate goal is to have end users running Linux or FreeBSD, and every project we've undertaken since the initial migration has brought us a little closer to that goal. Slowly but surely, we're making our way there.
Works a treat though. Web interface, client updates, complete call tracking, very easy to customise, email interface. Best thing for what we do. It does not want to control my hardware audit (which is done separately) it simply tracks calls. Does what it says on the tin.