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
Make sure you don't tell them about slashdot.
Return the bells of Balangiga.
I don't know why people think of a product as open source or not when doing deployment. Just think of it as linux or windows or mac or whatever the product is with whatever the feature you need.
How silly would it be to say to any manager, yeah... we're not deploying this because I can see the #includes and functions. That's essentially what people are saying, when they say no to open source.
How about Microsoft?
Read reviews of shopping cart software
Your company is very large. You must be using many open source solutions in many ways already. You should start there by identifing what is already being used and how effective they are. Thereby providing your own case studies.
http://Lenny.com
...is explaining it all to end users
It really depends on how your bosses understand the situation.
If they're more of the PHB kind, go "Linux is Free, we don't have to pay nothing, yadda..."
Now, in the "willing category":
1 - replacing WIndows w/ Linux at workstations may be a good idea. After all, their main use is Word Porcessing and E-Mails...
2 - In the server side, there are good choices too, but then there is support...
how long until
Though they may not be 100% trusted by the community, they do have resources and studies to help prove your case. Sometimes the slick presentation is valued more that the well-researched one, anyway.
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!
RISK
THE BOTTOM LINE
The latter is of course, tantamount in a for profit organization. Focus your research on these two items, and shy away from the "thousands of eyballs reviewing the code" arguments, as those are unlikely to carry the day.
Toodles!
Stop corporate
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
Make sure to highlight both the positive and negative aspects of the switch to open source from a user's perspective. That way if something doesn't work exactly like the higher-ups want it, you have covered yourself by telling them beforehand. You also may be credited with good foresight in the event that certain tasks / implementations are made to work better / faster. Again, make sure to cover both sides of the story or you may be in for some dissapointment or trouble.
I believe that the thing that needs to be addressed and stressed are the recent KNOWN vulenrability "outbreak". The fact that in order for one to keep up and deploy all the security patches that come out almost on a daily basis on all clients. One has to have dozens of man hours per patch. Which obviously translates to quite a bit of money.
How's that for a start?
-JemNo businessman ever trusts something that is argued to be "free". The saying "you get what you pay for" rings true with most management teams, and anything "free" is directly indicative of being poor quality. Cheap is a euphemism for bad quality normally. And switching to Open Source is not free, indeed it is often not even cheap. The costs are real, but so too are the advantages.
I don't know about your IT department, but for many more than half the price of a PC is Windows and Office licences. Stopping those is a dramatic cost-saving.
Your company will almost certainly want continuing support for its systems, this will have to be budgetted for. Don't forget training costs, your workers will need to be retrained to learn how to use the new systems and this costs money. There are more costs but you get the point.
Do a genuine cost-benefit analysis, work out all this, especially support and training costs, and it will still be dramatically profitable to switch to Open Source. However a fully polished, professional and complete cost-benefit analysis will provide very useful and significant information to management, in a form they can understand and trust.
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
Cheaper software makes it easier for small businesses to grow, and large businesses still need the support and tech's to impliment this software, so they hire, spend, develop, and contribute (via GPL). Anything that lowers the cost to start up and grow a business is good for jobs, good for the economy, good for consumers who now have more choice in the market place.
CMDRTACO CHECK YOUR EMAIL!
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
You are fortunate to work in a company that is open to open source. I work for a large software company (10000+ employees in several states), and the official policy is that nobody uses any open source software, because if somebody sues us there isn't a company we can turn around and sue. This is seriously the primary reason - I've had one-on-one discussions with our lawyers on this issue.
Personally, I violate that corporate directive on a daily basis - I run linux, I use mozi^h^h^h^hphoe^h^h^h^hfirebird^h^h^h^hfox, etc. I do have to rdeskop to a windows box for corporate email and to use word+excel, as many people in my same position have to do. But 100% of my development (java) is done on linux.
This post is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 License.
Assuming you're advising management, or perhaps the CXO level, what you want to focus on is cost. Price. TCO.
Executives don't give a flip about "open source," or "contributing to the community," or "furthering the Free Software movement," etc. Executives do care very much about what they're spending on IT.
Consider the cost of 60,000 Windows workstations vs. 60,000 Linux or FreeBSD workstations. Do some calculations based upon the Windows licensing scheme vs. "free." The differences will undoubtedly be astronomical. Don't push the "free" aspect over the top; factor in the legitimate costs of a) switching existing workstations to an open source OS and b) supporting users migrating from Windows to the OS you choose. Any open source OS will still come out way ahead, even with the cost of switching.
Finally, I would advise that you forget what Gartner has to say, unless your superiors are totally sold on Gartner results.
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....
I think it is most important that the ROI be measured in an effective method. Such as, not only look at the obvious costs, but look at the hidden savings from changing to Open Source. Such as, we are running Pentium II computers for a year longer since we are running Linux, which extends the life beyond the cycle of expected depreciation. We can cycle in upgrades to hardware in cycles to prevent a one time expense on the balance sheet.
Then cover things like the amount of power saved with the older machines using less watts. For some companies, this could be $100,000+. EnergyStar has statics on this information.
I would also mention the recent losing of the source code for Windows along with the ability to break free of recurring charges with virus software.
In the grand scheme of security, it would probably be beneficial to note that spyware and corporate theft is less likely in a system that is unfriendly to script based theft schemes.
Mention that you don't have to worry about paying for MCSE for employees. You have no fears of employees stealing licenses.
No more formatting when a new employee inherits a machine.
The ability to disable Cd Drives remotely at will.
I guess that covers the basic things. I would give them all copies of Linux LiveCDs that they can take home and use on their home machines. LindowsLive is a good one to use. Let them see for themselves that it is not going to be a foreign OS, but just a slightly different OS.
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
:-)
Here you are. I hope that was helpful
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Simply couch it in terms that most big biz managers can understand, the days when mainframes, dumb terminals and programmers ruled the earth. The largest data center I've ever worked in was First Chicago - National Bank of Detroit's Haggerty Rd. Tech Center, and based on that experience (and at smaller data centers) I see no problem with Open Source taking over most of the software functions from the OS to applications to custom programming for one-off jobs. The main thing to remember about Linux and OSS is that most of it needs to be used as large Lego's, nice blocks of code that do their job damn well, but need smaller custom machined parts if you need to go outside the boundaries. This is the reason IBM is behind Linux and therefore OSS, you can still make a hell of alot of money actually making the whole thing work. I hope your tech team is like most of the ones I work with; love to read and learn new things, enjoy long hours in the night and weekends spent with keyboard and mouse, and the courage to kludge and break things in a test environment, but the control to leave out the kitchen sink if the plumbing stinks.
Jonah Hex
Horror & SciFi Erotic Nudes
I recognize up front that I may not be the most objective soul on the planet, speaking as a web/database developer working exclusively on a free software platform. What follows would be my list of potential gotchas concerning questions we've been asked by clients:
(1) Since you are a member of a company that's subject to rather scrutinous regulatory and privacy concerns, you would definitely need to develop a solid policy for code auditing. Yes, I tend to trust the core developers of most major projects to watch patches and such pretty closely (especially with OpenBSD and Debian), but mistakes can happen. You'd probably need to consider the cost of keeping an in-house audit team (a few good coders) to review new releases under consideration for your production environment. These people don't come free, but I'm pretty sure they'd be less expensive than (a) implementing the applications yourself in-house, or (b) going with a propietary solution (which costs money up front) and then STILL having to audit the code to be sure.
(2) In relation to item (1), I'd be sure to cover the fact that just because a company has a closed source product doesn't necessary make their developers any more trustworthy than highly regarded community development teams. Reference the Sybase backdoor debacle for some concrete proof that nasty things happen in Fortune 500 companies. "Having someone to sue" doesn't necessarily mean jack when your company is getting hounded by the Feds for improper information disclosure.
(3) I'd try to focus on tech segments where open source solutions are already extemely well tested and in general acceptance, such as Apache for web serving. Again, some internal problems may really benefit from a chained solution using existing OSS projects and toolkits, but these are probably a touch sell that would be better left alone until other projects are firmly grounded. Possibly exempt from this rule would be broad projects such as the Perl programming language, although you would probably want to add a policy subsection on module auditing as well (since CPAN is just so darned comprehensive).
That's about all I've got for now; I'm a bit tired from a late day/night of bug fixes. Hope some of this helps.
Sig: Seeking partnerships with web design firms.
I work for a massive-global corp and getting an OpenSource policy in place would be impossible. My suggestion would be to start with a small group. For example, the group I'm with has been denied licenses for PowerPoint do to cost reasons. The solution was to distribute OO to our team members so that we can create PP compatible presentations for distribution and viewing.
If you were to identify those kinds of groups that have been denied or lack software packages do to cost reasons, then you might be able to make similar in roads.
If your company seems resistant to Open Source for whatever reason, include a package from Redhat or Suse that includes support (such as Redhat enterprise.) Business types will prefer buying into a product/service package as opposed to a solution/process package. Then you can ease them into the idea of running pure open source software over time.
My Other Computer Is A Data General Nova III.
I assume you won't be going open source for everything, but will rather evaluate on a need-by-need basis.
As you evaluate each need, some special questions apply:
- Legal: Do we want/need legal recourse if something goes wrong with this piece of software?
- Do we plan to extend and enhance this product ourselves? Are we willing to share our work with the larger OSS community?
And for each OSS candidate:
- Liveliness of maintainers: are they issuing regular updates? Are they meeting the needs of the community?
- Conversely, does our organization have the right skills to help update the software?
- Is the userbase big enough to ensure decent longevity of the product? (Safety in numbers)
- Do we need and can we get tech support that meets our SLAs?
There must be a bunch of other questions to be asked, but you get the idea. Again, I suggest you treat OSS as one tool to help you on a need-by-need basis, rather than the answer to your business' cost savings dreams.
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
What information do you think should be included to sell Open Source to management at the top-level of any corporation or business?
Ok, this is going to attract down-mods the way that posters named "I'mASingleGeekGirl" attract up-mods, but I have to say it.
Why should we care about "selling" open source for internal business use? Now, I don't blame Stokey for asking -- I'd do the same. And I guess if you're a *nix admin, the more companies using open source, the more business you have. Point taken.
But if you're not a *nix admin, why do you feel the desire to give free advice to a company that's never going to give you a dime? Why do we treat open source like it's a religion that we need to "witness" and proselytize for?
Sure, in a few cases, if a business starts using open source, they'll contribute code modifications back to the community, or maybe even hire a few coders from the community.
But in most cases, the company is just going to install linux and postgresql and Open Office and the open source community won't get so much as a thank you.
And besides, these businesses are forever telling us how much they know, how brilliant their management is, etc. If these men of brilliance can't figure out that $0.00 per seat is less than $200.00 (or whatever the figure is after corporate discounts), that few viruses and exploits are better than the never-ending waves of windows viruses, that never being audited is far less disruptive than repeated visits from the BSA, if the MBA geniuses tat run these companies can't figure this out on their own, why should we Slashdotters who aren't invited along on the expense account lunches sweat to convince them otherwise?
I mean, if no company ever used open source again, there would still be hobbyists producing open source code. and that's a straw man anyway -- companies that want robust servers already use linux in droves.
It's like we all grew up as geeks in hisghschool (ok, I guess we all did) and now that we have decent jobs and decent wardrobes and no more acne, we're still tripping all over ourselves just because a pretty girl -- the "legitimate" business -- smiles at us. How about saying to her, if you can't figure out why you should want me rather than the bloated slob from Redmond with all the viruses -- well, I'm no longer so desperate and lacking in self-esteem that I'll beat my head against a wall trying to convince you.
Again, I'm not saying we shouldn't try to convince companies to go with open source; we should. I'm just saying I think we shouldn't be -- we needn't be -- so desperate to do so.
Opinions on the Twiddler2 hand-held keyboard?
- Have your policy/standard give prescriptive guidance about when you feel it is - and is not - appropriate to use open source. I'm not saying there are necessarily cases where you may not want to use open source, but there may be. For example, our shop is a big WebSphere user, and for us that was a strategic choice. We have good operational competence at running it too. So, just because some project came along and said "we'd like to use JBoss", that would be a good example of when not to use open source - for us, anyway.
- For cases where you do use open source, make sure that the sponsoring project for some particular open source tool has clearly identified how it will be supported in production. This may be the team itself, it may have chosen to outsource, who cares... But, make sure they do identify a source of support. Otherwise, when stuff breaks a 2AM, the ops folks will just call *everyone* in...
...probably including you.
- Make sure that your General Counsel's Office is thoroughly briefed on the various kinds of open source license agreements, and that they are ok with the license for the particular open source tool when it is "acquired". Some licenses may not be compatible with all commercial usage (LGPL is probably the worst offender from this perspective), and thus careful review is appropriate. In any case, if you don't get your GCO on your side, they'll shoot you down in flames...
- Make sure that your policy/standards differentiate between where it's appropriate to *use* open source, vs. where it's appropriate for you to *contribute* to it. There are at least two reasons for this: a) if no one gives back, the quality of open source software will suffer; and b) there are often cases where it's better to give up both work (as well as "intellectual property") rather than doing something proprietary. For example, three or four years ago my own company had decided that we needed an MVC-based front-servlet design. It proved very handy, and as projects like struts came along, we just dumped some of the core ideas into that project. Over the long-haul it is much better for us to have our needs supported directly by open source products, than it is for us to have to build a bunch of proprietary goo.
- You will likely have another fight on your hands with the aforementioned lawyers on the idea of contributing to open source, but it's worth fighting for. (Our own GCO just didn't get this, and I'm not sure whether they fully do yet. They have a distinct feeling that our IP rights are such that we should own the universe.)
- Expect a fight. There will be a certain number of folks "from the Dark Side" who view open source as a threat to Civilization As We Know It. Take no prisoners with these types...
Good luck!"The time is always now" - Victor
The first argument that I heard was "We will have to develop our own distribution" rather than rely on Redhat or SuSe or something like that. This is particularly true of financial institutions who must be very concerned with their ability to audit exactly what is on their machines at all times.
With open source comes the question from developers, "Will we be able to contribute changes back to the community?" The answer is almost always "No" in the big companies because they feel that it makes them responsible/liable for those changes. Worse, this sometimes develops into the black hole of "Get it off the net, integrate it into our stuff, then never say another word about it. Don't even get new versions [we don't want to be dependent on them], just treat it like it's been ours all along."
Lastly, in order to use open source app X, be able to show that a vendor exists who will sell you support for that app. I heard that almost verbatim from a boss once -- Why Tomcat over JBoss? Beacuse he knew where he could buy Tomcat support, but not JBoss. (Whether or not you actually can buy JBoss support is not the question -- the fact is that a manager's world is limited to what he has read in Business Week or who he has talked to at the latest trade show).
Oh, one more thing. Keep religion and philosophy out of it. If your company really does want to go open source, they are most definitely not doing it beacuse they want to contribute back to the community, or because they believe that it is the new way, or anything new agey. They are doing it to save money. Therefore, sell it like that. Don't push your luck.
www.HearMySoulSpeak.com
Talk to your peers in other financial companies. I know quite a few use open source. Feel free to send me an email at michael_j_mangino@bankone.com if you want to talk about this in more detail. I can give you some information abotu what other companies are doing.
Mike Mangino
mmangino@acm.org
Policy is great, so is open source philsophy. But what sells the idea to management is the presentation of a cohesive plan for implementing the new software: variant & feature selection, configuration controls, distribution to & training of users, support needed. Comparing these to the existing way you do business will show the pros&cons of changing over.
The devil is always in the details...
Is it a rule, that there's an exception to every rule?
If a linux desktop is on the cards, why not do the better part of your presentation from a laptop with impress (open office powerpoint) and near the end of the presentation, you minimise open office and show them a ximian gnome, or nice KDE desktop underneath. Show them it is REAL.
I am a bit of a Gnome fanboy, but in the interests of OSS I'd say use a KDE that's been setup to be "windows-like" so they go "wow just like windows, but free".
On the server side, maybe setup a windows box and a linux one side-by-side and show them running a ContentManagementSystem (php+database) both on apache and say "the only difference here is a windows server license".
Sure IT overlords will want case studies and number crunching - but both Gnome and KDE and pretty impressive now for "wow" factor.
Detail how much of the size of Microsoft is also devoted to un-business like things - directx 9, games, drivers blah blah. And how there are people pushing a desktop "for business" that can have IMs, spyware, viruses etc. "locked out, so work can get done". Spartan systems are to your advantage here. "This isn't entertainment or home oriented, this is business oriented from it's base as a networked server operating system". Linux isn't a bunch of kiddies, it is system admins "trying to get work done".
Not to downplay the benefits an OSS VoIP/IM system could have on internal communication. Content management systems as "team work areas" that can be securely VPNed into to allow work from anywhere.
Play up all these things are corporate, not hacker made... even if they are not....
Play up Mozilla as an awesome productivity tool. "Funded by AOL and standards compliant this beast is all about a workers workflow management - take tabbed browsing for example".
"OpenOffice is driven by Sun as a standards compliant office suite - I am running this presentation on it"
"Redhat competes against MS server markets, and because they are specialised they do a better job"
"Novell is driving ximian to be the best work-force desktop - look at these colaboration options, compatible with MS servers too"
"IBM is putting their weight and experience behind this, and is swapping to linux internally themelves as we speak."
Get that "Unix industrial grade" aura rather than "community this and that".
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 am the IT Director at a much smaller (100+ employees), so this advice may not wash in just a vastly different culture. I have found that it is much easier just to do it, and then point to it when it is up and working at a reduced cost. I have found great success in this approach.
"Here are last year's costs...here are this year's costs. Wow, is that a lot less or what?!"
YMMV, of course...
Linux
Apache
Mysql/Postgresql
Perl/PHP/Python
Simply make it okay for your employees to install this technology on their computers, because it is great technology, it won't lock you in, and it is becoming a global standard.
It will be much easier approving a couple good Open Source technologies than creating a general policy for Open Source technologies.
Once management sees how great the above work, they will be much more open to additional addons to your list of approved Open Source programs.
The future is Open.
Sdelat' Ameriku velikoy Snova!
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!
While (as you rightly pointed out) it is quite clear there are advantages for and against individual opensource an proprietry products, there is also an argument to be made for opensource in general.
This is not to say that every open source product has better (or even equivilent in some cases) functionality, but that the very fact that it is open source has benefits. For a large multinational such as the submitter is enquiring for, one of the big wories must be ownership and continuity of support for whatever product / projects they use in their IT infrastructure.
Pick a proprietry product, and a company going bust or mearly becoming uncooperative could result in a large risk to your ability to maintain your internal infrastructure - be it through bug fixes or introducing new features.
By choosing an opensource strategy, it will always be possible to either maintain such systems internally, or shop around for someone appropriately qualified to make the changes you need. Purchase and maintainance TCO are good arguments, but IMHO the biggest factor to large multinationals will be one of reduced risk, and therefore there can be a benefit by choosing a lower featured opensource product over a traditional proprietry one.
Just this morning on the news, the talking heads were yammering on about the alleged leak of NT source code. On comment jumped out at me: "some [security researchers] are worried that hackers will be able to use the source code to find new vulnerabilities."
Chew on that for a moment. If the only thing keeping Windows from being 0WN3D on a daily basis is that hackers can't see the source code so they know exactly what function is vulnerable, then how secure is the code? We call that "security through obscurity," and it's really no security at all.
Of course, Open Source means that those same hackers can read the Linux or *BSD code to look for vulnerabilities, but so can a lot of people who are interested in making the system more secure.
Consider the scenario: a F/OSS developer discovers a huge security hole in the code for the FooBar 1.1 release. It will take a huge amount of effort to fix, and so the F/OSS community will have to continue using FooBar 1.0 for 3 more months. Irritating, but manageable.
Now consider if it's a programmer at MS or any other commercial software outfit. Will your customers wait 3 more months? Will your boss appreciate the impact you just had on the company's finances? Might the bug be "papered over" in order to not impact delivery to customers? Is that really in the best interest of the customer, especially if the customer is a large finance company?
-paul
Pistol caliber is like religion: everyone has their favourite, and theirs is the only right choice.
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
I run a 6000 user network in the healthcare industry. The first thing I had to do here was dispel the stupid myths such as open source software is insecure because so many people can change it. This was difficult because of the power of the Gartner Group and other orgs like them. In fact, the network manager was so Microsoftized, it took going over his head to the CIO in order to get people to start listening. That was quite a risky move but luckily it worked.
The second thing I did was set up parallel apps that mirrored the same thing the company was doing with their closed sourced systems (Windows). This included setting up squirrelmail to connect to the Exchange servers, setting up Linux-based SSH boxes (we had SSL-based FTP) and setting up a Snort box to rival the ISS IDS that was installed. Once they got a taste of how good (and cheap) the software was, management starting coming around. Another thing that helped was the software that I mirrored on Linux boxes were apps that we had been experiencing consistent problems on. The Outlook Web Access and the IDS servers kept crashing so that was easy. The more challenging one was the SSL-based Windows FTP server. I prevailed when I got our customers to start requesting SSH client access (a little comment every now and then doesn't hurt). Most of our customers were running a UNIX-based system so once they found out that we could possibly start using something native to their systems, they started requesting it through our sales reps.
It also helps to get in good with your business partners' IS department.
The issue that you will have is based on cost. Most large corporations (like the fortune 100 company I work for) have a mentality that open source is free. The code is free, the software licensing is free, but is there a cost?
Most people don't understand why they (being large corporations) call things open source instead of by the name of Linux or ___BSD. What it comes down to is what they are considering. They define many projects that use "free" or "open" software as open source in an implied type of meaning relating to support cost in most cases.
What most people fail to realize is that with a commercial "closed source" product, the company that sold it to you is expected to support that product. If it has problems and the wizbang features they market to you break, then you go back to them and tell them to fix it. After all, you paid them for it and it should work. One other thing to consider is that many software companies have a very strict QA testing environment. This doesn't mean the software is better, but rather that the company that purchased the product has someone to point a finger at when it breaks and someone who will be more obligated to correcting the issue.
With open software, it is quite different. Most of you know that bug fixes are done mostly on spare time of coders helping with projects. There is no solid support of software like you have with commercial software. You may consider mailing lists and bug tracking pages to be support, but thats not quite the same as being able to pick up a phone, call the developer and say "Fix this!". While many developers in the open source community have a sense to help out, many don't. So you are not garaunteed support from them. The other thing to consider is with such a large environment, who does the end support? Most large corporations pay for end support through their vendors they bought the software and products from. With Linux, what companies can provide that?
There are options like getting with RedHat or some others offering "Enterprise" solutions, but if the goal is not to pay for software, then you will pay dearly for support. Then again, it's my experience working with RS/6000 systems that my company pays for the OS/Systems and for support both, so who knows. Just keep in mind that support is a major fact.
root 10956 5164 0 Oct 22 - 0:23 sendmail: rejecting connections: load average: 70 (isn't sendmail just too kind)
Now I have to state before I make my comment, that I work for a small college with around ~5000 students. And working in Academia is a bit different than working in the corporate world. We use opensource software here (Linux, apache, squirrelmail, netsaint, and a few others...), and it wasn't that hard to get in the door. Mostly because it's cheap (budgets are tight) and it gets the job done. Plus, both the network admin and I know Linux, so the college does not have to spend money training people who can use opensource software. I don't care what microsoft says, if you already have a linux/unix admin employed in your company, then your TCO for Linux over windows is practically nil.
But anyway, with that said, one thing that I've noticed here at the college, is not so much a hesitation to use free/opensource software, as there is to make sure that it's supported properly. See, our budgets are stretched tight with microsoft products, so if we can save money or even go with a free solution, then it actually is welcomed. But what they really want is someone to point the finger at if it breaks. Now if your solution is homebrew, then they point it to you and you have to fix it. (not necessarily a bad thing. That's how our account-creation on campus works. Buying a product would have been too expensive) But being able to rely on another company for help is a big plus.
I know that companies like RedHat and IBM may have their own interests at heart (like RH not releasing new free versions outside of their fedora releases) but if you can get a support contract from these guys that says that they will back up their software, then that's often what you need to turn the tide. So long as the software does the job, and does it well. All you really need to do is just get its foot in the door. Once you do that, if the products work just fine, then you'll have much less resistance to getting more software in the door from there on out.
-Through the server, over the router, off the firewall... Nothing but 'Net!
Hope those references help.
- David A. Wheeler (see my Secure Programming HOWTO)
This letter and the examples following below convince me that the push to convert to Linux-Open Source will not come from the developed world's corporate environment, but, rather, from the undeveloped world.
Linux-Open Source will be adopted there first because there won't be the money available to buy Microsoft or other large private closed software solutions. As the developing world's entities grow larger and richer over the years, they will become the force that will be most successful at convincing wealthy corporations to develop parallel open-source software stuctures to Microsoft-SAF-Oracle, ect...
In this light, it is to Microsoft's advantage that the entities with limited resources for software in the developing world continue to use easily pirated software. People will use pirated Windows when they are poor and as they get more resources they will buy licenced versions of the same software in order to reduce linkage costs with global institutions that have used proprietary software since day one.
It would be in the interests of the open-source community to demand software companies put as much copy protection and install encryption techniques as possible on their products!
1) Make sure that every point you make is backed up with fact and research. Avoid religious level proselytizing. Just becasue you (and I) are already sold on FOSS doesn't mean they're going to accept that information without supporting data. Remember, as a senior leader in any organization, their jobs are to play devils' advocates and plan for the worst case scenario when evaluating now projects and expenditures. Allay the fears that they may already have. It would be wise to read Microsoft's anti-OSS propaganda pages and rebut, in your first paper, all of those claims that relate to your organization.
2) Write with a hefty respect for "What could possibly go wrong?" Anticipate objections and rebut them in your initial report. For each FOSS product you're planning to use, explain how you can make it redundant (ie. failover web-server/database serveR) and how you can recover your backups in the case of data loss. If you can make your current backup solution work with your alternative OS servers and apps, that's a big benefit! As you can imagine, protecting their large, director level salaries is a big concern for the PHB's today. Make them understand that support and recoverability are not the exclusive domain of proprietary vendors. They might approve switching some in-house app from SQL Server to Postgres if they know you will still have full functionality and recoverability without spending a mint ripping out the backup software/hardware and starting over.
3) Make the point that FOSS is perfect for some needs, while less suited to others. You have a better chance of having your ideas accepted if your message is "right tool for the right job." Is there any reason that file and print server should run Windows 2003 Server and require 2 gig of RAM and dual XEON procs when Mandrake, Samba, and Webmin would achieve the same goals on a lot more modestly appointed system.
4) Don't forget about hardware! Point out that software that uses fewer hardware resources will require less frequent hardware replacement. A new linux kernel doesn't mean everybody needs new hardware... Compare with each new iteration of Windows having an ever exponentially-increasing list of hardware requirements.
Beyond that? You're on your own. Oh, and to quote Bob from "That 70's Show": "Hit him with a banjo."
Who did what now?
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.
The poster of this 'Ask Slashdot' probably makes 2-3 times what I make (if not 10x-20x in stock options alone) and yet he's willing to listen to my poorly informed ideas on such an important matter?! Truly hilarious!
Sometimes folks get promoted into positions of power and influence because they realize that the best answers aren't necessarily the ones you pay the most for. Indeed, isn't that one of the major selling points of OSS--that paying more does *not* always get you more?
A request for opinions is exactly that. You didn't really think he was going to use your opinion to supplant his own, did you?
Dan
A "Policy" is not a selling document, nor even a how-to. It provides guidelines to make decisions, biased to what the corporate executives want. In this case, a policy should contain items like:
1. When planning a new software activity, see if there are any open source candidates.
2. If there are any candidates, they must be investigated (with criteria like the parent of this comment proposes): risk, history of support and bugginess of releases, real adequacy for the task, TCO estimates, etc.
3. Produce a report comparing and contrasting the proposed solution with alternatives, and the rationale for a choice.
I.e. in terms business people can understand. Other information should be elsewhere.
Between the FUD that Microsoft and SCO have been throwing about, most non-technical people will have a very confused view about things like the GPL and open source IP issues. You have to be prepared to address these in simple, easy to understand terms and examples.
For instance, a lot of people get scared by the 'viral' GPL FUD, and think using open source products means they have to release all their own IP crown jewels to the public. You might counter this by pointing out that you can write closed source software with open source tools all you want, and only run into trouble if you actually incorporate their code into your product. Because this is something you couldn't do with non-open source software anyway, as you never see the code, the percieved risk isn't a factor for doing things the way you're used to.
Anti-open-source people have been throwing a lot of FUD around lately. The people you are trying to pitch this policy have heard some of it, and probably don't spend lots of time on Slashdot or Groklaw finding out the whole story. Part of your role is going to be to dispel all this FUD about the GPL, IP issues, and such.
This is tangentially related, but the seven areas in which he measures benefits to a business of going green can give you ideas about selling OSS to businesses.
There's a good chance we could make a case for OSS in the three main drivers he identified:
One last, important point: the author pointed out how many of these companies (and he only surveyed high-tech ones) kept finding high-ROI opportunities. Go after the low-hanging fruit, stuff that makes a measurable impact in under a year. You'll get better at finding them.
Information: "I want to be anthropomorphized"
In my opinion the greater risk is the risk of not moving to open source in a dignified manner. As time goes by licensing from Microsoft is bound to get more restrictive, cumbersome and expensive. With open source your organization is secure in knowing that current apps will be continually improved and there won't be "licensing surprises" in the future. As organizations gradually move to open source Microsoft will have fewer customers from which to derive its profits and, to maintain revenues, prices will go up - leading to yet more people moving to OSS. When the tipping point is reached every organization had better have an open source contingency plan in place. The longer they put it off the harder it'll be at crunch time. In essence it comes down this. Looking into the future 5-10 years from now there are nothing but blue skies in the direction of open source and a lot of dark clouds and uncertainty in the direction of MS. Any large organization would be fool hardy indeed to stick their head in the sand while the predictable market forces play themselves out.
This is a great time to be involved in open source.
Congrats for drawing such a difficult but worthy and rewarding assignment. I have a couple thought s for the policy.
It must encourage and reward people for finding creative and effective open source solutions that save money and increase productivity.
It should make provisions for continuing research, and have a framework for studying recommendations made by individuals. Possibly by committee.
Doing these things will take steps toward the creation of an open source 'culture' in the organization. It gets people interested and involved, and gives the IT management a throwback when people cry that they don't like this or that.
Good Luck!
--Fargo007
They're less costly over the long run, have a BIG company behind
:-)
them so the old "but who do we go for when we need tech support?" dilemma is solved, they run Microsoft Office, are easy to use and powerful.
Even I have a hard time recommending Macs at my job, so I can't imagine what trouble I would have if I were to recommend a flavor of GNU/Linux.
It's all in the way you present it, and how you can educate others. Show them examples of compatibility, have a "test" computer on the network for a month to show that GNU/Linux can not only sit on the network, share files, open those files, and be useful for work, but it is also safe, good-looking and free.
Cost is either a primary issue or a final issue. Meaning?
Primary issue: We need something cheap!
or
Final issue: Sure that's nice, but it's cheap/free so it must have
some hidden costs or be a wolf in sheep's clothing
Either you go to buy something for the price, and not the quality, or you go for quality and price is figured in last.
Show M$FT alternatives based on power, speed, ease of use,
and quality. Once they see that, hit them with the price tag.
At least that's what us Mac zealots do to win over PHBs.
Although I haven't had the opportunity to give this talk yet, I've been keeping my eyes open to what people are saying where I am. A lot of other people have made good comments, I'll only state the key points I would make.
I got nailed a few months ago in a discussion on this issue by someone asking the question of an internal group that was proposing to develop an application based on an open-source framework. The question was simple: "What happens if you decide to leave, how do we support it?" All the arguments that came into my head wouldn't work, those evaluating this were not technologically savvy and could care less about actually having the source (few people actually do care about that, a point made strongly elsewhere). In a pure George Castanza moment, afterwards I realized that although there isn't a good answer to that question, there is a very valid rebuttal question: "What happens when the private company who you purchased software from goes out of business/gets purchased/stops supporting that product?" At least to me, it was a new way to look at the same question, and since that's probably the most common question that will come up, since people are always looking for support, it's very important.
Other than that, two things: (1) check cio.com because they have a lot of articles and research on how to sell open source to your business people, and (2) don't be a zealot, they can smell it on you, but approach it from a rational business angle and have answers/rebuttals to the typical questions (see above) and it will impress the business types, who could honestly not care less about the religion of open source.
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 have been let down by more software development houses than I want to remember.
Despite the fact that you pay them thousands of pounds a year, they don't tell you that your management console will not be able to rollout the latest anti-virus update until it breaks. That is what I am paying for.
Or the latest patch of a Major OS will systematically kill every single Network Card authentication signature in the registry. That is what I am paying for.
How about being lied to by sales department that tell you that this software will work with the systems you have in place. They don't check with their technical department and wait till our purchase is complete and when I try to install I find out the bad news. It seems that it crashes your server and has consistently done so for the past month on all other servers of your type that it has been rolled out on. That is what I am paying for. Thank you very much
If you look at it over the past 8 years, I have had more success with every single open source product I have rolled out than the multitude of proprietary software that I have deployed over the years.
So don't give me this will open source live up to the trends set by proprietary code. For me they have already surpassed the quality of proprietary code.
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.
Bottom line, this is the real power, to obviate the allways tenous vendor client relationship. You are your own vendor, and bottom line, no-one in the world can meet your own needs the way you can.
You can push that theme in lots of directions, but it all seems to tie back to being able to control your own destiny with your software acquisitions.
Hell that what finally convinced my employer to begin in-house dev again in lieu of buying from an external vendor. (Well, the vendors ridiculous pricing didn't hurt either...)
"Talk minus action equals nothing" - Joey Shithead, D.O.A.
"Talk minus action equals
Is open minds. I have found in my wanderings around the IT world in the companies that I have worked for that there a large number of people who are only capable of rote tasks in a sandbox of M$ products. The concept of being able to generalize from M$ office to Star Office is totally beyond them. Heaven help them if they see a different gui for their mail program. In that case they are totally lost. This is in contrast to folks who master a number of enviroments and understand what happens when they hit return.
I suggest that these M$ only folks are NOT the folks that a company benefits by hiring unless you want an army of mindless drones. Some places may want that sort of person, but I doubt that they are the companies that suceed in life.
In my opinion Gartner would be one of the least reliable sources of information on open source software, TCO, ROI, etc. They earned their reputation on supporting proprietary solutions and in particular Microsoft. In the last two years, however, they gradually modified their stance and now are more couscous, especially since the security problems of Microsoft are undeniable.
One possible place to look for help are actual case studies and down-to-earth approach for business solutions such as Andrew Grygos' article "Should Your Business Use Linux?" - you can find it on: http://www.aaxnet.com/editor/edit010.html.
Since I also do IT consulting, my advice is to focus on what applications are used by employees in what departments. Can those be substituted with open source software? In growing number of cases most office programs can be substituted with OpenOffice and CrossOver combination, or better yet with SoftMaker suit that is becoming a very reliable solution for office work and includes file formats for MS Word, etc. Their website is: http://www.softmaker.de/index_en.htm
By doing TCO, say with SoftMaker, it is obvious that open source solutions win big time against MS Office, etc.
IP was invented for the sake of lawsuits.
" ... nearly every workstation needs to have QB installed so we can get our job done. ..."
... is it really true? Do you need Quickbooks on every workstation? Because if it isn't true, then you have a world of options.
If that's true, then you need QuickBooks and Windows on your desktops.
But, I as you
QuickBooks is a glorified database. A database could be described as essentially the oldest application use for desktop computing; it was around on the Apple ][ and is on the list of the first 3 apps you need to launch a platform. Everybody's got one.
What do you use? QuickBooks. If you look at it that way, it's the only answer.
What do you do? Aha. Way different. You are using a database to manage your business. Now you can move to damn near any platform, including Linux, and get "double-click" functionality. It's all how you look at it.
Make sure you ask the right questions, and you get the right answers.
..because what you're going to try to do is my very business. We're doing OSS migration and OSS project customization for small copmanies and _very_ large corporations (Pharmacy) and I'd could come up with a billion things to say. Since I've been working this field all day for a few months without an end I'll cut it short:
The world of closed source has ended. Period.
It's that simple. I wouldn't bet another single dime on a company focusing on a businessmodel that concentrates on the selling of closed source. Hell, even Macromedia - one of the few that actually made a steady revenue with closed source, mind you - has set up their newest product as a _service_ ('breeze') and not as the usual enveloped CD in a box of air!
Not convinced? Do it the other way around: Tell me why _should_ a company _go_ closed source? Stick with it till it's amortised? Ok. SAP has another few years, maybe even a decade, and only a maniac would try to migrate a company the size of, let's say, Volkswagen, from SAP to a custom compiere or GNUe enviroment or something simular right now. Nuclear Plants are also a special thing. But they are in various ways and are somewhat another league where closedness or openess doesn't really count.
For all else goes this:
Every day I'm helping companies do the transition and make the first steps. These companies are in time. In 5 years from now we'll all be the computer software craftsmen/women and MS and Co. will have a hard time adapting. The companies without the awareness to leave the update treadmill will just waste another round of cash and lose it in the end.
Closed Source has had it's day. It's really that simple. If you're building something new or restrucutring, follow up or waste big money. That's all there is to it.
We suffer more in our imagination than in reality. - Seneca
I am familiar with most of the arguments for OSS on the desktop, having made them as a sysadmin in a M$ dominated network at my previous job. You look at the services deployed on the server, the applications running on the desktop, the database and start thinking... hey, I know! We'll run sendmail instead of Exchange, OpenOffice instead of Word, Mozilla instead of IE and mySQL instead of SQL server! And we can probably all consolidate it onto one system which also acts as a gateway and a firewall with ipchains--
I'll save them about a billion dollars over the next 10 years and they'll worship me as their GOD!
And even in a small environment, that would take some time. Interoperability issues aside (document formats, drivers for that old tape backup-drive? forgot about those) you're looking at a whole new psychology change (getting used to a new GUI, "Where's my internet" kinds of questions), and that will make the end users hate you and the management hate you as well (as everything will seem "broken" to them). Sure, *if* you got them migrated seemlessly, you'd be saving money. Eventually.
But in an enterprise? Forget it. I mean sure deploy OSS on some test servers where they're used to UNIX anyways or whatever, but replacing all the desktops across the entire enterprise would be just crippling in (re)training costs alone. Not just for the users (wasted time) but for the Tier 1 folks as well.
My (admittedly unsolicited) advice would be to give OSS just enough of a reputation that someone says, "Hmmm. We should look at this." Then it'll be piloted somewhere in his organization. Once the kinks have gotten worked out, then he could actually have the company-specific data to induce a global change.
--Have a good night's sleep. Don't forget to brush your tooth.