Slashdot Mirror
The Benefits of 'Vendor-Free' Open Source IT
mjasay writes "IDC has released a report looking into industry adoption of open software. In the study, analyst Matt Lawton stumbles across an intriguing trend: IT departments do most of the services around open source, rather than third-party consulting companies. While IDC believes this is a bad thing, the data in the report suggests otherwise. 70% of the enterprises surveyed did their own implementations, while roughly 90% supported their own open-source deployments. This might be a cause for alarm if the projects weren't so successful: 70% of the projects were deemed to be of "Critical" or "High Importance" compared to other IT projects and 90% plan to maintain or increase their investment in open source projects. Could it be that open source is liberating enterprises from an unhealthy dependence on vendors, and that early results suggest that this will be a Very Good Thing for the success of IT projects, many of which have failed historically."
Very interesting thesis of this post. In my line of work (health care) there is a lot of in-house development of patient care record systems, as there is not a dominant standard at this time.
I've found the following:
- You get smarter, more resourceful people when they are not MSCE drones, but actually programmers that are able to solve a problem, not just relay it up the chain or find the checkbox in the configuration GUI.
- There is much less waste in a way, and more in another way. Specifically, implementing a solution often involves talking to a single person about a problem with the database, not finding the "Oracle consultant guy" who then can talk to the "Microsoft guy." With a department that has its own development, these things seem to go faster and there is less separation of functions.
- However, many hospitals / organizations duplicate functionality, which is the "more waste" that I talk about. I mean, many, many businesses are the same and need email / web server setups plus a few business-specific apps. This is all duplicated by each organization. Training a consultant is even more globally efficient in this regard, who can take his expertise and start multiple implementations without (expensive) retraining.
Overall, I think this is great news for smart people going into IT. You will be sought after to lead a company department, and all of those license fees can now contribute to your salary + additional savings for the company. Would you rather earn $x from being a MSCE admin, or $5x managing a vertical open-source system with much more intellectual stimulation? I'd take the latter.
Slashdotter, ID #101. UIDs are in binary, right?
You know what they say. 53.74% of statistics are mad. up on the spot.
I mean come on. You have 4 percentages. Two of them are 70%. The other two are 90%. How big was their sample size? 10?
so what? the replacement support path for open source products = independent consultants.
Yes big time money grubbers, well educated techs can become competitive to your so called 'natural' capitalistic corporate machine without mounds and mounds of investment capital... and they will deliver, exactly what customers want. Work done. Not packaged marketing hoopla and FUD.
Terrible security: who knows where the software is from.
Legal concerns: Lots of stolen code.
Bad quality: geeks don't like to finish what they do, just do the "fun" parts.
No testing: geeks don't like to test.
Laughable documentation: geeks don't like to communicate with users.
Expensive: Hooked on the initial $0 price, customers get shafted on support.
No help: Open source support, especially paying one, rarely brings solutions.
And on a global scale, damage to the economy, reduction of research and knowledge production, moving of capital to foreign (and potentially ennemy) countries, providing technological material support to terrorist groups.
Open source? It's bad..
It might be good if the laws were better. For instance, more patents, and more prison time for violators.
(you know it's true)
Linux violates 235 Microsoft patents.
Sure, a lot of these may be Open Source, but I know of a lot of companies that have Open Source software installed by commercial vendors (e.g. Red Hat or even IBM).
Now, this may not necessarily be a bad thing, but I don't see how this is markedly different from, say, paying Microsoft.
You're still paying for support and stability -- just that you have a little more flexibility and control over your software, which usually does not matter all that much in enterprise production applications. I mean, just often do you recompile your kernel or add a new feature on your platform handling millions of transactions a day for a critical client? I didn't think so.
I mean, yay for Open Source and all that, but so what? At least from a customer perspective, you may not be paying for licenses anymore, but you are still paying for support -- and that is usually where the bulk of the expenses lie.
This might be a cause for alarm if the projects weren't so successful: 70% of the projects were deemed to be of "Critical" or "High Importance" compared to other IT projects..."
This post reminds me that most slashdotters are engineers, and not project managers. How in the world do you infer that the projects are "so successful"?
The article (which I did read) does claim a large percentage of the projects are "Critical" or "High Importance", but this does not mean, "These are the successful projects." Rather it means, "These projects had damn well better be successful!" Are they successful? No word on that.
This is another example of posters' bias, reading conclusions into an article that does not support them.
Come back when there's some history of these internally supported projects. Let's see if they do better than the dismal 50% average success achieved by today's corporate technologists.
"Could it be that open source is liberating enterprises from an unhealthy dependence on vendors, and that early results suggest that this will be a Very Good Thing for the success of IT projects, many of which have failed historically."
So were on sourceforge can I download an Air Traffic Control System?
Ten guys @ 120k a piece who are collectively computer experts in web design, web development, front end application development, linux, windows, mac, graphics, and networking will solve 100 times more problems 20 times faster for any organization compared to 100 4 year educated drones @ 60k.
;)
Truth....hurts.
Frustration with lack of decent support from enterprise software is exactly the reason I switched to Linux in my work apps in the first place.
I develop software for electronic toll collection systems. In 1997, that stuff all ran on things like UnixWare 2.1 with VenturCom real-time extensions. It worked fine when it worked, but if you ever uncovered a bug that was difficult to solve, forget it. We once encountered a problem with the UnixWare 2.03 C library that caused a memory leak every time a file handle was written to. The fix? Upgrade to UW 2.1. Except, the realtime extensions package we had would only run on 2.03. What we needed was a patch to that version of the OS. SCO's answer? Well, that isn't our problem now is it? VenturCom's answer? Buy a new version of our extensions.
After experiences like that, I decided to switch our projects to Linux. In 1997, support for the near-realtime features I needed (memory locking, adjustable priorities, POSIX signals) was pretty poor under Linux, but it was worth working around it to get away from the corporate OSes.
The sad part is, my bosses initially refused to allow me to do that. The reason? There was no official means of support, we would have to maintain the software ourselves! To them, the concept of "support" was just a check box you ticked off somewhere, not something they actually ever had to use. And they had no idea that it was simply easier to go out and find a fix, or fix problems yourself, than to rely on some multilevel telephone hell that usually doesn't know anything in depth about the products it is supposed to help with.
Ironically, today, practically every embedded system in the toll and intelligent transportation industry runs on Linux; it has become the industry standard.
Most information about how to tweak these are found quickly by using Google, while many commercial packages are cumbersome and also sometimes requires configuration in many places/modules using a variety of user interfaces to be both safe and stable.
What often happens is that when a support issue actually occurs it can cost a lot of time to straighten out while trying to contact a vendor but it is likely already fixed in an open source package one way or another. What many analysts fails to see is that each support case can create a downtime that has an impact on both support personnel and a lot of people depending on the service.
"The time to fix" factor is seldom seen in an analysis like this.
There are of course also open source packages that doesn't work as well, but the author is often aware of that and has probably inserted a huge disclaimer stating the limitations. And how many times have you seen a limitation declaration in a commercial package? (Unless of course it's a liability limitation).
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Preferred-vendor (or preferred technology) approaches are OK until your business problem can't be helped by an existing off the shelf component. Rather than go for large scale bespoke development, the result is often large scale package customisation and integration, with most of the same disadvantages. Either of these need decent in-house business domain knowledge, which pure IT services companies can't provide, which is why some of them are aligning to industry segments and not just technology. But if you did have a decent in-house development team, that is where the pay off comes - people who 'can' *and* people who 'know'.
I don't know about healthcare, but in many other sectors, they have already moved away from having deep technical skills aligned to their business and their IT environment. Instead, they have been sold a set of packages with some glue to stick them together, plus some consultancy to glue them together. There is an in-house service delivery organisation who are there to service the machine, but they don't get asked to build new stuff. This is a shame since some of them used to do that work and enjoy it more than investigating support calls. SD will have expertise in the majority vendor (e.g. Microsoft on the desktop/office infrastructure side, Oracle on the server/db side) - but more for support than development or enhancement of applications.
The business as a whole sees a lower baseline cost for IT, with individual units (HR, marketing etc) paying for expensive projects by outside consultants, whilst accepting the trade off between the disadvantages of this model against bottom line costs.
SCO comes to mind. I know of a number of companies that ARE dependant on SCO. How is their service? Not so great. Also, the same thing happens in the closed source world. That is, companies like MS will say that you MUST upgrade to their next version. If you do not, then you have the issues. How many companies are actually running Win31, Win98. NT, win200, etc? Loads. Can they get patches? Nope. Not a one (save a new virus).
OTH, imagine if you buy Oracle linux, and then they are bought by MS. What do you think that MS will do to the Linux? Yeah, that support will stop day 1. Or course, in this case, you siumply switch to redhat or anybody else that offers support.
I prefer the "u" in honour as it seems to be missing these days.
Where I work, it seems to come down to
(a) Spend several ten of thousands upfront and the another few thousand every year on a commercial product. Never have it integrate like they promised it would. Wait weeks or forever for fixes. Repeat every three years. Or..
(b) Buy a couple of servers. Spend time I would otherwise have spent trying not to fall asleep putting together what we need by gluing together a few open source systems. Fix it when it breaks. Maybe it takes a few weeks. But we always get there in the end.
I'd be much happier paying good money for commercial 'solutions' if they weren't pretty much always rubbish. And by rubbish I mean plaintext auth over http, I mean wasting a week whilst vendors argue over whose problem it is - without actually investigating, etc etc.
If want less-than-perfect products with substandard support, I can do that myself.
Why are you looking at me like that?
The article has a chart, labelled "Primary Source of Project Services".
And the line on the chart that struck me was the most was the one labelled "No other services required", with responses in the 20 percent (or more) range.
That means one in five projects, relying on Open Source Software, requires no support whatsoever (other than what the developers do for themselves, I presume).
That suggests that the Open Source Software they are using requires very little, if any, support.
In other words, IT JUST WORKS.
Can you imagine a project that relies on Windows, or other Microsoft software, that can get along without someone assigned to support? Heck, even a simple home Windows user has to know or hire someone to provide support, otherwise their PC ends up being used as a doorstop.
This matches my own experience. My son provides my PC service. When I was using Windows, I had to ask him for help every couple of weeks or so. But then he installed Linux for me (Debian, Gnome, Firefox, Thunderbird, OpenOffice), and he hasn't had to touch my PC for almost two years. Linux has never crashed on me (though Firefox has).
I know that my son also converted a small business to Linux (servers and desktops), and now they don't call him unless they want something new added -- they never call him to fix something that's broken, unless it's a hardware problem.
This means that, when it comes to Total Cost of Ownership, Open Source software is not only cheaper for the initial installation, it is also cheaper in the long run, due to reduced problems, and reduced support costs.
Don't you find it funny that a paper about Open Source costs $4500?
good if your management are smart enough to realise the value of the people who work for them, but usually they don't see this.
If you mod me down, I will become more powerful than you can imagine....
When I was young I heard a saying "Nobody ever got fired for buying IBM". The concept of this is that if you were buying a computer system and the project failed, you could not be faulted for it if you had picked IBM as your vendor, while if you chose a different vendor your choice would be questioned and you could lose your job. This same mentality is applied to operating systtems and software now, but substitute Microsoft for IBM. Perhaps this is starting to change. It is fascinating to speculate on a world where IT managers would be questioned for their decision to choose Microsoft. "You implemented Vista all over our corporation? Why did you do that?"
Now, this may not necessarily be a bad thing, but I don't see how this is markedly different from, say, paying Microsoft.
It's massively different. With Microsoft you're locked into their file formats and their upgrade cycle. You can either dance on the end of their patch string or leave your network vulnerable. I'm constantly surprised at how much MS dictates the daily activity of MS-centric shops.
The best value with open source is to implement it yourself. The next best thing would be paying someone like IBM to do it for you. If you get mad at IBM you have the option of finding someone else to support your operation and give them the boot. If you try it yourself and run into problems, you can always get out the checkbook and call in the big boys.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
Except I was coming at it from the angle that companies waste a fantastic amount of time and money on software vendors. The fewer you have in the mix, the more value in your IT systems.
Too many companies are locked into dysfunctional vendor-lead relationships. They're getting advice and resources from another company in business to sell them something. It's bizarre but I see it all the time.
The best value with open source is to implement it yourself. If you get into trouble you can always whistle up IBM or HP to ride in to save the day, at breath-taking charge rates, of course. Just depends on where you want to spend your money. With Microsoft you're paying for the licenses AND support. Where's the value? With OSS you're paying for support.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
First of all, what does IDC mean by "attendant services"? When I hear that, I think of the old half-blind guy that sits in the john at the rippers, handing out towels and cheap cologne for a tip. And trust me, kids: there's no way you're getting that second lapdance with wet hands and B.O.!
Jokes aside, are you going to call up your local best-of-breed Certified Middleware Synergizer (TM) to setup Subversion for your in-house Web developers? Not so much.
Rolling out Asterisk + SugarCRM on OpenVZ for the inside sales division? Probably.
A "Critical" or "High Importance" project isn't necessarily difficult and may not require any additional support beyond the (usually good) documentation and online support channels.
See this for what it is: IDC, yet again, working some vague numbers for a weak conclusion to sell an overpriced research paper.
body massage!
Vendors assume you are ignorant of their products, especially as how it pertains to your own environment. Try it sometime, call a vendor and say, "I'd like to order 2 _vendor_ _model_, with X numbers of these add-ons, can I get a quote?" You won't get a quote for anything you ordered if the price tag is over a couple hundred bucks. They will happily sell you the little stuff, but the minute you order a large product, you become an idiot to them, who has to be walked through a slow and tedious process of "carefully examining your situation to ensure we find the right fit." yeah, shutup asshole. I researched this a ton, I know what this product will do, what I need it to do, I have found your 'right fit,' just quote me a price and lets get on with this. I do not need a four way phone conversation between you, the manufacturer's sales guy, and two techs explaining me a pile of stuff I already know. You are not going to sell me a product that is 10 times my expected price, I am not an idiot, when I said I wanted model Y, I meant "I want model Y!" not, "I am an idiot, and if you sweet talk me hard enough, I'll by the YY2000eleventyOverpoweredDontNeedItonlyMoronsBUyThis model"
So yeah, fuck Vendors, we do 99% of our stuff in house, we are a FreeBSD shop with a ton of custom code. I like it this way, it keeps me off the phone with sales guys and snobby support techs. When it breaks, I fix it, not pick up the phone and pray they aren't having a high call volume.
--Nuintari
slashdot : where an opinion can be wrong.
Linux (and some open Unix variants) are the only operating systems with source code availability. IBM z/OS, AIX, HP-UX, Sun Solaris, and Microsoft Windows are all closed, black-box binaries with no source code.
In almost all IT shops with open source operating systems, it is child's play to modify an OS routine and compile it to run innocuously on an IT-managed server. Who is looking for modified OS code on a random web server? This ability to rather freely hide nefarious code is what gives nightmares to IT auditors -- and to the outside auditors and regulators who must under Sarbanes-Oxley certify the IT processes behind financial reporting.
Unfortunately, the visible in-house IT savings in avoiding a support contract with, say, Red Hat, are outweighed in the long run by the costs of fraud and increased audits and controls. But you'll see few IT executives standing up to do something about the problems of open-source-enabled fraud.
Our company doesn't currently pay any outside people to support our open source usage but we'll consider doing so on a as-needed basis. The vast majority of problems are stuff that is familiar to anyone that is experienced at working with the specific software and within the open source community but if something was new and above our abilities we'd pay for support.
We are paying for support for a large proprietary ERP system. The software was expensive, requires expensive hardware (only runs on IBM), and support is quite expensive. The software is buggy, missing obvious features, and is poorly documented. The support is often poor and most questions can only get answered, if they can be answered at all, by talking to a manager-level person in the support department or even to someone from development. The entire experience is much worse than working with open source and does not leave me with any desire to use more proprietary software.
I'm actually thinking of choosing an open source ERP project and sponsoring having the features we need added to it. Even if it took several years to bring the open source system to par with our existing system I think it'd be the better forward track because we could then switch systems and have the features we need, that the current system doesn't offer, run on our choice of hardware, and have the great support offered by open source projects. If we made this switch we'd also want commercial support though as the system would be mission critical. We'd use in-house support, community support, and commercial support to cover all our bases.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
all open source projects are by definition successful. Failure would be if they used closed source, and if they used microsoft it would be a disaster.
Sure, why not? If the free software was not a success it would quickly be replaced by your other options who's costs are known. Most of these companies have been there and done that.
You are witnessing the rise of free software. It has already taken over embedded systems, HPC and other "server" applications. The whole point was to provide a community sharing building blocks that would benefit everyone. User generated software serves users. The other stuff serves it's owners. The trend really is irreversible.
What a ridiculous strawman. Any company where it's child's play for an unauthorized person to install a new OS (free or not) on a production machine needs to fire all their IT people.
Why do you trust disgruntled employees in software companies to not similarly sabotage your operation?
Unlimited growth == Cancer.
Linux (and some open Unix variants) are the only operating systems with source code availability. IBM z/OS, AIX, HP-UX, Sun Solaris, and Microsoft Windows are all closed, black-box binaries with no source code.
Now, before I go any further, are you certain about that?
Even back in the Dark Ages on the 1980's & early '90s UNIX vendors used to provide kernels object code to allow the end user to re-link kernels. It's how we used to roll before someone realised loadable kernel modules might be a good idea.
So basically you're trotting out a tired old troll without even taking the time to get basic facts correct. Excuse me while I yawn.
Of the Operating Environments you mentioned, source is available. The last "hold-out" was Microsoft -- even they make source licenses available now.
HP: see http://licensing.hp.com/slm/swl/view.slm?page=source (VMS, Tru64)
Solaris: completely open-source, see http://opensolaris.org/os/
IBM: not sure about them -- older releases of IBMs mainframe OS came with source, so I expect that z/OS comes with source. I *haven't* personally seen the source for AIX.
In general, OSs have ALWAYS come with source; back in the early '80s, for example, Digital VMS came with source (by default on microfiche AFAIR). The "closed source" OS was debuted by CP/M, and carried forward by MSDOS.
Just another "Cubible(sic) Joe" 2 17 3061
Also every good project manager I have ever met was also an engineer...
I have the same experience. But also, most of the very worst project managers I have worked with started as engineers. When I was starting out, engineers became project leads, and then project managers, as if they were automatically qualified by their experience in coding, design, etc., to organize work breakdown structures, schedules, status reports, and risk mitigation. Many engineers never learn how vital these are to the success of a project, by providing truthful information to sponsors.
I eventually learned how to manage projects by acquiring a large set of skills and habits that bear little relation to development. And my early technical experience makes me a much better manager than people who trained as project managers without going through the technologist experience.
It's not all that more difficult to run binaries on those systems as well.
I can throw myself at the ground, and miss.