Slashdot Mirror
How Would You Argue for Open Source?
Nate asks: "I am currently working for an international corporation, and the site I am working at was (until very recently) entirely run on Windows. We recently purchased a Solaris server, and I am in charge of setting it up and resetting the global UNIX standard. The problem is that management doesn't want to install software that does not have 24 hour, worldwide support available along with it, yet they want the capabilities that only open source software can provide on a UNIX platform (VNC, OpenSSH, etc..) without spending insane amounts of money. I was wondering how the Slashdot community deals with convincing management that Open Source software is safe to use when creating a global standard, and what your solutions have been to supporting users working with open source software." Two years ago, Slashdot tackled the Enterprise Support question. Now, say you had that particular problem solved and the only thing left is that all-important pitch to Upper Management. What arguments would you use in your attempts to get their approval? What statistics and references would you point to, in order to back everything up?
"We'll have access to the source code, and be able to update the app as needed due to new requirements or OS upgrade."
Worked for me.
"If, therefore, any be unhappy, let him remember that he is unhappy by reason of himself alone."
~Epictetus
if they want to take responsibility for aligning their IT strategy to their business objectives, or their systems provider's.
"It's not your information. It's information about you" - John Ford, Vice President, Equifax
It seems odd to me to decide on a solution and then develop arguments to use that solution. IT is generally a service provider for business needs. You present the business users with the available options, outline the pros and cons, and allow them to decide. The other danger of engaging in proseletyzing is that if something goes wrong, everyone will be quick to point out the guy who did all the yelling about open source.
I know that there is information available on open source vs ms EULA. the doc I used was in the syndey morning herald. the beauty is, it shows that mgmt doesn't have "hand on throat" with software vendors. Thus, open source is no more risky. Also MSFT has never been successfully sued in 27 years!
My approach is to address the FUD right up front. Fear of license, fear of lack of support. Guess what? We don't have any now!!!
I guess it depends on how much money is considered 'insane'. RedHat offers support, HP sells contracts supporting Linux... I would think the support costs would not exceed a comparable contract supporting Windows systems.
.:diatonic:.
So give her estimated labor costs of installing and supporting MySQL vs cost of purchasing, installing and supporting Oracle. Don't forget hardware costs.
Talk about two things:
Cost: Cost of rollout of a commercial product is comparable or more than the cost of 3rd party support contracts for open software.
Risk Management: Buying proprietary software gives you support, but the support is with a monopoly supplier who can then choose to charge whatever it wishes down the road for both software upgrades and support. Tying yourself to a monopoly supplier is a poor risk, since every move a monopolist will make will not be for the benifit of your company, but for the benifit of thiers. Similarly, with Open Source, since our company has the right to modify the software, every change you make will be for the benifit of your company.
Upper Management does not grok Geek. Upper Management groks Dollars and groks Risk.
Just keep that in mind.
-- Funksaw.
that was the whole business model behind OSS: charge for support not for the software.
My penguin ate my sig
Now, say you had that particular problem solved and the only thing left is that all-important pitch to Upper Management. What arguments would you use in your attempts to get their approval? What statistics and references would you point to, in order to back everything up?
I wouldn't even bother. I would call the local IBM Global Services office and ask them to pitch for the job, and dangle the carrot (whether it exists or not right now, it might to in the future) of outsourcing the management of said Open Source infrastructure to them. I assume that you don't actually care who runs it from day to day just so long as it's Open Source. They'll make a far more convincing argument that you can alone - remember they employ people full-time to do nothing but research and put together fancy presentations (as do all consulting firms... you don't think the slick performers doing the presentation will actually show up to do the work, do you?).
What you need are testimonials from others running mission-critical applications using FOSS.
One Fortune 500 executive won't achieve comfort with this kind of a spending and deployment decision (face it, they don't know the tech) until, unless, and, only if, they have seen more than one other Fortune 500 executive put their own necks on the chopping block, made a courageous decision, and have it succeed wildly with no glitches whatsoever.
Getting those testimonials might be hard for an individual on their own ("Mr. Big's office, how may I help you? Right...."), but the web is full of articles showing different businesses using FOSS successfully.
If you were tied into a vendor with a lot of FOSS contacts (eg, RH, IBM), then they could probably help you find those important reference testimonials. Sun is late getting on board the FOSS bandwagon, despite having produced a lot the standards and technology that has made it possible. Their Solaris servers will run FOSS just fine and interoperate with Linux machines, etc.
"Provided by the management for your protection."
What makes you think that those developers were making "off-the-shelf" applications? It's likely that some of them are, but I'd wager that most are meant for internal use.
Ita erat quando hic adveni.
MS has stopped releasing security updates for NT4, so companies using it are forced to decide between having security holes or paying MS for a newer version that locks them into a more draconian license agreement. How long until your company faces the same problem with whatever version of windows they use?
With open source, you can patch whatever version you're running, or just upgrade whatever is necessary without the draconian eulas.
Jason
ProfQuotes
They'll ask you "Why go with Solaris over any other Unix variant?" Better have that answer.
They'll ask you "Why not Linux?" Have an asnwer.
They'll ask you "Will it work with our existing Windows infrastructure?" Answer that as well.
They'll ask "How much will the rollout cost?" Better have those figures handy.
They'll want to know "Why not just stick with Windows, especially since Windows 2003 is about to ship?" Have a retort ready for that.
They'll want to know (if they're savvy) how the data crunching numbers will compare UNIX to Windows, MySQL to MS SQL. You'll want that handy, too.
And finally, they'll want to know why should they switch to a different platform when they're already so heavily invested in Windows. Got an answer other than "Windows sucks"? You better know those things, becuase bosses aren't about to "just take your word for it" they demand facts, figures, and spreadsheets for proof--and if anything goes wrong it's your ass. Switching is fine, but you better be ready for the backlash and have oodles of proof ready or the resistance will be an unsurmountable chasm.
Easy. Stop making it a big deal. What you are meant to be providing is a solution that suits your company's IT needs. You are not the company Open Source advocater, shouting blue murder every time someone implements a system which isn't open source.
Use clear cut facts. Show the TCO, show the support channels, show the migration cost and schedules, provide a backup plan if things go pear-shaped, etc. Basically, the FACTS. And while you are at it, keep your own mind open. Y'know, often, closed source solutions are far superior than open source solutions. Don't be afraid to keep an open mind and have the openness to choose a proprietry solution if that is the best way forward.
And if you manage to keep an open mind, you'll be superior to the vast majority of open source advocates...
Before you go to upper management find out how much the non-open source applications are going to cost. Factor in any consulting fees for setup. Then factor in the cost for global support on an ongoing basis over say the course of the next five years. I'd also suggest adding in any special hardware requirements.
Next find your open source "products". Then find developers who are very comfortable with the "products" that you are recommending. Factor in the cost of hiring them and their salary on an on going basis. They will be your "support" team. Also factor in hardware if needed.
The first hurdle is to prove that it will cost less or at the very least no more than the "off the shelf" products. Then you'll need to put your sales hat on and do a side by side "feature comparison" of the OSS alternatives to the products that you evaluated.
Most of all, be objective and very matter of fact about your presentation. Prove to them that OSS is the way to go becuase it costs less to aquire and maintian and has an equal or superior feature set. Apache is a great case study...
Good luck!
the capabilities that only open source software can provide on a UNIX platform (VNC, OpenSSH, etc..) without spending insane amounts of money.
Since the two examples you cite are available on Windows, perhaps you need to get a better understanding of Windows. In fact, Windows Remote Desktop feature in XP is superior to VNC in functionality, response, and seamless integration, so VNC is hardly a compelling argument in favor of open source operating systems.
Perhaps you need to have someone with a more balanced perspective come into the organization and evaluate where Unix derivatives are the best choice and where Windows is a superior pick. Those who blindly promote *nix and open source as the solution to every computing problem are no more enlightened than those who automatically choose Microsoft products for every function.
Why do you think that they're going to be anything other than in-house apps?
Heck, I expect to write a Linux app in the next year. Frankly, I expect to be doing it in under 6 months. And nobody will ever see it since it's the core infrastructure for a service my company is offering. Pure backend stuff.
The vast majority of software written is not written for the commercial marketplace. It's written for inhouse use.
I work at a university, and over two years ago, they asked me to help evaluate authoring systems for online courses. One of their requirements was that the company we chose needed to be willing to partner with the institution to extend the capabilities of their software to meet our needs. We gave several suggestions, but I told them they should get on board with MIT's OKI and OpenCourseWare.
They had two concerns about open source solutions: 1. There is no company behind most open source solution. No company means no tech support. 2. OKI was just getting off the ground and would not be ready for prime time for a while.
Over a year later, the university finally chose a company to go with for their authoring system. We paid for a 30-day trial and got 5 days into it before we realized their marketing people had straight-up lied about its feature set.
So, we went with the company our university had ranked number two on the list. We worked with them for 6 months, hired one of their people to work for them on a university paycheck, and gave them a substantial fee every month for licensing. Then the company decided to get out of the authoring systems market, pulled our license and left us with nothing.
In the meantime, OKI has picked up steam, and the 11 universities that got on early with them have been developing solutions that will soon be GPLed.
The long-short is that having a company behind the product is a double-edged sword. Sure, they could give you tech support, but what happens if/when they're gone?
I'd rather have someone respond than be modded up.
Also, if you're talking to your manager about being "bent over" and using the term "BS", you're not in the most professional of atmospheres and might consider getting out.
I hate liberals. If you are a liberal, do not reply.
The only arguments that make any sense to bean counters are ones that may be reduced to dollars and cents. All arguments should be of the form: If we do (not)? X, then we will save Y over Z years for the following reasons: A, B, C,.... If you cannot reduce the argument to ROI, then there is no business reason for doing something - Mind you, ROI takes on many forms - You need to apply your insider perspective to figure out an ROI model that your management will swallow Forgive the RegEx notation
No kidding. Upper Management never seems to remember it's not THEM building the network, it's you. So they're concerned about how THEY will look if something does work, well, that goes both ways. If YOU are setting up a crap network, not only will you be the one coming in on off-hours to repair it, but your voice will carry less and less weight as it gets worse and worse..
That actually piggy-backs the consulting Ask Slashdot from a few weeks ago.. If you're going to get stuck supporting garbage, and you know it, speak up! While the money may be good in the short term, the company will probably pay someone else to put something new in because you've been associated with the garbage.
"I can't give you a brain, so I'll give you a diploma" - The Great Oz (blatently stolen sig)
Personally, in your position, I'd build several possible scenarios...
That would be a minimum, the important thing is that every one of them has to achieve what the company needs. The costs will differ, the risks will differ, the long-term implications of things like scalability will differ and these will all play into the management viewpoint. They dont care how "good" the software is or isnt. All you can do is the risk analysis and the cost/benefit presentation, making them aware of precisely the levels of risk each solution exposes the company to and precisely how much it will cost to avoid those risks. Every software package is a risk, whether open source or not. Every piece of hardware is a risk. Lose your main production data server and how much business do you lose per hour whilst its down? How long will it take to get it back in each of your scenarios? How likely is the outage in the first place? Since every solution you present meets the same needs, does it matter which one they choose?
Now, my personal opinion based on experience in the past is that when the analysis is complete the case for open source in at least some of the application areas of a unix environment will be a complete no-brainer. As you work up the results, however, you might be surprised at some of the places it doesnt give an appreciable benefit. Remember that the time you spend scripting and configuring stuff is part of the cost, as is employee learning time. Dont leave anything out. Be absolutely straight presenting the best comparable info you can and dont try and slant it either way. If they make the wrong choice and it bites the company in the butt it then wont be your fault, even if the wrong choice was your recommendation too.
I had a
In addition to other arguments made above, never lose site of what really motivates the decision makers. They are not techies, they are 'business people'.
Three key buzzwords for you to use relentlessly:
R.O.I.
R.O.I.
R.O.I.
When you keep hammering the topic, sooner or later, a key decision maker will figure out how to convert the IT budget slated for the MS tax into a nice fat bonus for himself and then *bingo* your company will become an OSS/FS haven!
Just as irrigation is the lifeblood of the Southwest, lifeblood is the soup of cannibals. -- Jack Handy
Maybe she is 'right', but she's a bitch.
Anyone who uses TLA's like TCO for short ideas like labor costs is fucking stupid.
My advice?
Kill her.
Sure - they've been doing Veritas support for free for Veritas for years - you'll find they've got the same approach to a lot of the common opensource stuff they bundle in as well (openSSH, OpenOffice, bash, tcsh, etc .. - heck you might even find that their employees were prime contributors to the code, but never made a big blue marketing stink about it ..)
People make decisions for their reasons, not for yours. They don't care that it will make your job easier, they don't care that it will run better, they don't care that it will save you time and frustration.
So find out what they do care about, and then sell it to them based on those points. Don't mention why *you* want it at all; talk all day about why *they* want it.
(Incidentally, you can copy and paste that response with almost no changes for any "How do I convince..." question.)
--- 11 meters/second, or 24 miles per hour - the airspeed velocity of an unladen European swallow. Really.
This is why most pure tech people generally cant get things done (or done "technically" right); because they sometimes have an inability to provide things that are asked for.
Management and Tech are two different languages. Your boss was telling you how she wanted to explain it to HER bosses, and you basically said "oh, I dont feel I need to". Well, when she doesnt feel like listening to your suggestions in the future, you will know why.
I get ahead by making my boss's job easier, not harder.
Manipulate the moderator system! Mod someone as "overrated" today.
But she has a perfectly valid point. When MySQL breaks, are you the only/best option for fixing it? Do you really consider yourself that much of an expert that you could handle any conceivable problem that you might face? What if a hardware problem causes data corruption? Would you know how to recover from that? What if a library incompatibility comes up in the future and breaks MySQL. Would you be able to troubleshoot that and get the database back up? How long would it take you to do that? What if you run across a problem you have no idea how to resolve? Are you confident enough in your ability to find a solution via newsgroups or mailing lists?
Now what happens when you're on vacation? What happens when you've left the company? How does additional staffing (and training, since it may be very difficult to find a MySQL guru as smart as you might be) factor into your costs?
The point is, from an enterprise management perspective, things aren't as simple as some of us think. We think, yah, I can support this pretty easily. I haven't had a problem yet with it that I haven't been able to resolve (given enough time). Now ask yourself if that's sufficient for the project, or if you're going to need something or someone else to fall back on.
The "guru" support model works very well for smaller businesses, but frequently has major problems scaling to support an enterprise.
Now, I'm not saying that you (or someone else) might not have problems with this anyway (given that MySQL is actually fairly popular), but others reading this might not have the same luck with any OSS project. Just because the source is available doesn't mean it's cheaper to use than a commercially-supported product.
Well, i think than that licence is illegal.Except ofcourse when you live in the US, than it is legal as long as you lack the money to prove that it is not:)
Will someone please point to ANY example of a successful lawsuit against Microsoft (or IBM/Sun/HP for that matter) for producing faulty software that impacted someone's business???
The whole "gives us someone to blame" is a complete crock of manure. I used to write software for government apps... they always built a one year warranty into the product. Guess what we spent most of our time doing? Trying to prove a reported bug was actually a request for a new feature.
As far as contract support goes... those tend to be "time and material" peoples.... never seen a successful lawsuit there either...
There are plenty of companies which specialize in support for Linux and Open Source.
I mean really, you don't need to pay millions of dollars for support, though it is more difficult to find 24x7x365 support with 4 hour turnaround when you're talking $10,000/year instead of $250,000.
Then again, does your company really *need* that level of support? I would venture to say that they probably don't. If you build redundancy into your systems, you should be able to get by in most cases, albeit under heavier load. For 24x7x365 support, expect to spend $$$$.
According to your description, your employers have given you a clear, comprehensible and not unreasonable-sounding mandate: don't deploy any software that doesn't have 24-hour, world-wide support.
Why not, then, do your job by finding and implementing packages that fit their requirements, rather than wasting their time trying to shoehorn in unsupported crapware because you happen to think it's K-Rad?
As a rule, companies that have requirements like the ones you describe have them for very good reasons.
News for Nerds. Stuff that Matters? Like hell.
Consider this: Digital Equipment Corp. was once the #2 IT company in the world, with a huge software portfolio supported by an army of "world class" IT professionals. In the late 80's their products and support were awesome. Then it got ugly. By the time Compaq bought the remaining scraps, the "world class" software portfolio was sold off in bits and pieces. Where are those products now? Where is the support? If I had invested heavily in any DEC's software development tools, it would be a total write-off today. GNU is still there, isn't it?
When you buy a commercial software product, there is a real risk of failure, for all the reasons described above. When a manager makes a committment to a commercial software package, he or she can expect to be held accountable for what happens to that investment. If you start with open source products, the approval chain is generally short-circuited because the expenditure of $0 is with almost everyone's approval range. If the product fails to perform, you walk away from your investment of $0 and migrate to a commercial package. Of course, the people who sell commercial products are well aware of open source, and each has a reasonable migration path. Try calling Microsoft and tell them that you want some help in switching from Samba to Windows 2003 and watch them open the floodgates of support. On the other hand, if the OSS product performs well, you demonstrate the success to every level of management that will listen, calculate the ROI and deploy even more open source products in the future.
Now let's consider the risk the other way around. You buy Windows 2000, Microsoft IIS, and SQL Server because M$ has wonderful 24x7 commercial support. But Code Red, Code Blue, Nimda, Klez, and SQL Slammer come along and now your server is now owned by a 12-year-old who is renting it out as a spam gateway. The criticism for a technical debacle is bad enough, but then you get the CEO asking why it was necessary to spend big money AND face this nightmare when open source alternatives are proving to be somewhat more secure at a much lower cost. I doubt that my CEO would say such a thing, but open source is now getting coverage in Forbes and WSJ, so you never know. If you had installed Linux/Apache/MySQL and the same thing happened, at least you don't have to explain how the purchase price is now a total writeoff.
There are many people who use risk as their logic in support of closed source. Having seen more than a few defuct products and vendors, I say that risk really is the central issue, but that open source risk is more managable.
What?! And have yourself replaced by a monkey! Are you insane? :-)
zWhat would an EWOULDBLOCK block, if an EWOULDBLOCK could block would? -- me
Buddy, you REALLY need to keep this to yourself.
You don't want to come off sounding like a wounded pig now, do you ?
Besides, it seems like you ex-employer had a problem with the f***wit stuff by your own admission.
A few hints on how to manage your manager - for the next time you get into this situation.
Your manager is there to help you succeed. If your manager does not think that, then you've got the wrong manager and you need to get out quick smart.
That argument only works assuming you have people in your company who actually have the skill to play with the source code. It seems that the longer I'm in this field, the more apparent it becomes that there are only a small number of people who actually know what's going on when they look at code, and maybe a smaller number who have actually have the skill to modify it to their needs.
Also, if you're talking to your manager about being "bent over" and using the term "BS", you're not in the most professional of atmospheres and might consider getting out.
You haven't dealt with many "tech" managers, have you?
In my entire career (roughly a decade doing primarily firmware engineering with an assortment of "normal" coding as well) , I have had exactly two managers with a clue.
One I consider really decent, he knew what I did, and more importantly, he knew what he didn't know and wouldn't challenge me on decisions about things he didn't know.
The other "knew C", and for the most part stayed out of my way and let me do my job. Incidentally, for any management-types reading this, you should aspire to meet this description - At least know the basics of what the people you "lead" do, and if you can't literally do their job for them, just leave them the hell alone. Give 'em a project and go back to your cube for a week.
All the rest (I'd say over a dozen) believed that their pathetic little MBA meant they knew more about how to do my job than I did.
Put simply, PHBs really do exist, and count as the majority (in my experience) of managers.
Now, I don't mean to say they serve no purpose - I don't claim to understand the business world, so somebody better know "step 2" of code -> ??? -> profit. But when accountants give engineers crap about purely tech-oriented decisions, they need to ask themselves "do I want the job done, or do I want to prove my cluelessness to people who already consider me of dubious value to the ''team''?"
Incidentally, regarding tech support, I have found it wanting for any real usefulness, other than a false sense of accountability for the PHBs. At my previous job, we had a rather large tech support contract with a company that provided a particular embedded OS to us, and when something went wrong, guess who ended up solving the problem? WE provided THEM more bugfixes than they provided us. No kidding or hyperbole involved here. They would always respond with "we'll look into it", and of course since we needed the code working "yesterday", we'd have to start working on their bugs on our own. On two occasions that I can remember, we had to send an engineer to their HQ to explain their own major architectural flaws to them so they wouldn't continue sending us "fixes" that re-broke what we'd already worked around. Sad.
Your management has legitimate concerns, but these can be addressed with some open source packages, if the project is sufficiently mature and well-supported. This is where I see you making a common mistake: you speak of open source software as if all open source projects are the same.
For some of the very well-known open source projects -- such as Apache, much of what constitutes Linux, sendmail, Perl -- the documentation is excellent, the online resources are extensive and up-to-date, there are many opportunities for simple customization, and above all, there are full-time consultants and consulting firms who know the stuff very well and can be hired to help. In fact, if the latter is true, then your management can get exactly what they're looking for: full-time support.
Many other open source projects are obviously someone's part-time diversion, and it shows. There are many missing features and a few bugs, and no one who can get around to fixing them. The options for configuration and customization are limited. The documentation was done as an afterthought, it has whole critical chapters saying nothing more than "TBD", and it was apparently never proofread by a native speaker of English. (Sorry to have to add that last one, but unfortunately it's an all too common problem.) This is the stuff your management wants to stay away from, and they have good reason.
You mentioned two specific services you need: VNC and SSH. So why don't you research the quality of the available open source solutions? Evaluate them with respect to project maturity, online resources, quality of the documentation, and especially, find out if you can hire someone to provide support. I personally don't know what you can get, but if you're lucky, you can present your management with a professional solution that will satisfy their needs. And if you can't find that, then you shouldn't be going with the open source stuff anyway -- then your bosses may have saved you from a lot of heartache.
Always keep a sapphire in your mind
If you base the argument on that, you are fighting a battle you can't win.
Your battle should be about choosing the best tools for the job.
Yes, the fact that a tool is open is a plus... but seriously..
The reason many of us would rather use linux over solaris is NOT because of the cost.. it's because linux is more flexible and has more tools readily available. IF linux cost the same amount, we would still choose it.
I don't get the feeling my post was read (and yes, I have about 25 years experience with NASA, USAF contracts, telecom, Intel, web services, secure networks, etc ranging from programming to project management and CIO).
You are correct: no one "got fired" for buying Microsoft just like no one got fired for buying IBM in the 70s and 80s. However, IBM backed their product up big time (and lawsuits were less common then anyway). I've worked in Microsoft development shops (partners'R'us) at multiple levels and MS support was generally useless. Often we were explaining to them how their software was working (or didn't work).
My point was that the "accountability" excuse is a crock... there is no *vendor* accountability in the legal or monetary sense in our current environment. There is no one to sue if proprietary software fails.
You are also incorrect: you get fired if your solution doesn't work -- not on the basis of the components being Microsoft, Sun, HP, or Open Source.
It will be interesting to see if the Korean lawsuits start a trend toward software accountability...
Last install VNC ans ssh on solaris. Don't tell them. First look at the sun cd full of extra's. If its there then its supported by Sun and its no big deal.
Also look at there website and make downloads for solaris there. If they question the software tell them its from SUN.
They invested alot of money in hardware and bussiness has no sense in sunken costs or bad investements.
If arm twisting was used just to ditch Windows then by all means keep you mouth quiet. Someone likely betted his reputation and his job on Sun.
Solaris is a good OS. Expensive but good and is a Unix just like Linux or FreeBSD.
Running open source software on SUN will let Linux or FreeBSD later on after they get used to running it.
http://saveie6.com/
--you seem to be asking how to become a salesman when you are a technician by trade. It's not your expertise to do "sales".. You know what tools and products you need to accomplish your IT tasks. You then assemble the list that fits the criteria that you know will *work*, with the included contacts to the shops that actually sell the 24/7 support. You can make the initial contact, seek bids and some additional information, narrow your list to the best possible contacts, then introduce these people to the people in your shop who will be making the decisions. Your boss gets to be "the boss",make the decisions, he's happy, the service contract guys are happy-everyone wants the work, you are happy, you get the products you want and that back up service from when the problem or you are out of the loop for one reason or another. Everyone is a winner! It's up to THOSE shops sales staff to "sell" YOUR bosses on their service, initially based on your analysis and recommendations. They are way more suited to the task, that's their job, and if you are a good IT tech, you will know what you want, what is the best for your corp, and will be able to sort through the market speak in the first contacts. In a specialised industry, use the appropriate specialists.
Red Hat's primary business is support, unlike MS which regards its primary business as writing code. The biggest difference between commercial open source support and proprietary support is that there is *more* support for open source software. Why? Because open source code is supportable by more than just the original vendor. You want support? You can hire the original coder or a third party. You can choose to debug the code yourself, add features, or change features. You have options.
What options do you have with proprietary software? Well, you can guess at what's causing the problem and change configurations. If the problem is an actual crash or something, you can reboot, reinstall the offending program, reinstall the OS. If none of that works, you can call the vendor (who will start by having you follow those three steps, along with applying patches, blame the hardware, etc.). The vendor may or may not be able to help you. Further, it is entirely up to them whether they give you real support or not (for example, if behavior is considered to be a feature, you cannot make a software vendor change the behavior). If they choose not, then there is no recourse for you (other than switching software).
A university where I worked considered switching to one of those MS license all your software from us and we'll give you a really great deal. As part of that, they considered moving the yellow page servers to the MS product. The deal was sold, they were ready to start. They asked MS to make a tool that would convert a flat text file generated from the information stored in the previous software's format into the MS format and MS refused. They had a nice point and click interface, and they expected the university to manually retype 60 *thousand* accounts with it. An overnight batch job would have become a multi-month project. Yellow pages info now resides on OpenVMS boxes with a custom written interface that took a couple of weeks to design.
"Support is important so it does not have to end this way. If Microsoft or Oracle can fix a problem then your own reputation as well as another employee's stays normal."
Interesting claim. You think that a company with 800 stations can call microsoft and have them send somebody out to fix the problem. That's the size of a small hospital. Go ask your hospital how responsive Microsoft is to their demands for support of flaky software.
War is necrophilia.
And with this case it's a calculable risk. They can look at the companies history, look at its business plan, value of stock, etc, etc.
With the way which stock markets currently operate anyone assuming that a stock price tells you anything about the state of financial health of a company is probably a fool. Especially where there are no dividends being paid whilst there are all sorts of stock options in place.
When it comes to Microsoft, IBM or Oracle, there's little doubt that the company will exist long enough to support the solution.
The company can still exist whilst completly pulling the rug from under you or playing the "it's a feature, not a bug" game.
Again, they CAN get a new version. It'll cost them, but compared to the cost of being completely dead in the water, it doesnt look so bad.
Maybe they are both "dead in the water" and need a new version. Because there is nothing which stops proprietary software from containing "logic bombs" to disable it whenever the publisher decides the licence is up.
A few hundred thousand dollars every decade or so (MS may release a new OS every 3 years, but real world people upgrade every 10 or so, most sites I visit still run NT 4.0) is nothing compared to "Oh Gee, we're out of business. The SAMBA team decided not to work on it anymore, they're writing a Pokemon clone now".
This dosn't really make much sense, if people can stick with NT4 they can just as easily stick with version whatever of SAMBA. The difference is that if Microsoft decide NT4 is "dead" then there is nothing which can be done about it. Nobody else can pick up the NT4 project and continue its development or provide support based on intimate knowlage of how it works. About the only senario which would get rid of both the SAMBA team and every copy of the SAMBA code is one which probably wouldn't leave any computers (or people to use them).
There may be one commercial software supplier (like MSFT), but there will be hundreds of firms willing to support it.
However willing they might be they are all handicapped by not knowing how the thing works.