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."

Conclusion Not In Evidence...

[Anonymous Coward]

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.

Re:Open Source != Free

[pembo13]

Neither the summary nor the article seems to imply that open source == free. but it is a waste of resources to reimplement things, just because only good implementation is proprietary and you can't afford it. Some companies still implement their own timesheet and issue tracking systems -- what if there was a good OSS they could just mod to suite their needs.

Re:Conclusion Not In Evidence...

[pembo13]

What a bullshit thing to say. A project is successful if it meets its slated goals in the agreed amount of time and expense. This has nothing to do with OSS.

A Perfect Team

[DigitalisAkujin]

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. ;)

Model at this point....

[ndg123]

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.

It's about relative risk.

[mawhin]

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.

Re:Model at this point....

[smilindog2000]

You know, there's another good reason IT guys support open source projects. When things go wrong, you just enter the error message into Google, and 80% of the time, the solution is right there! It's faster to fix open-source goobers than it is to call a support company. Google and open-source make you smarter than a paid closed-source consultant. Why do IT guys support open-source themselves? Because they can. Because it's actually easier. And... it's more fun :-)

No other services required = 20 percent

[Anonymous Coward]

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.

in house experience

[timmarhy]

The problem with this, is it requires keeping experienced people.

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.

CYA

[Anonymous Coward]

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?"

Re:A Perfect Team

[eraserewind]

Yeah, but managers prefer headcount than subordinates earning more than them.

Huge difference

[HangingChad]

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.

Re:Good news for those going into IT

[The Spoonman]

Interesting reply, but I work in the financial industry, and I find the exact opposite to be true. Most in-house developers are clueless dimwits who've fallen behind the times because they've been isolated from real programming techniques and newer technologies. They end up doing things the same old way for years at a time and nothing really changes.

You get smarter, more resourceful people when they are not MSCE drones, but actually programmers that are able to solve a problem

This would make more sense if you hadn't mixed the two. An MCSE is a person who's taken tests to indicate technical ability administering Windows-based systems. An MCSD is a developer who has certified on MS products. The two disciplines are completely separate from each other. Administrators make terrible developers and developers make terrible administrators. Yes, in the last 21 years, I've met about 5 anecdotal people who managed to be fantastic at both, but they were an extreme exception, not the norm.

That being said, those are simply certifications. They serve a singular purpose: to provide HR drones with checklists that they can compare resumes against. They do not, in any way, indicate a person's ability to do a particular job. It merely shows they were able to memorize answers to a test and spew them out. Generally, it's pretty easy to tell the clueless from the clued-in. The clueless have their certs hanging on a wall, the clued-in don't know where theirs are.

Re:Yup

[masdog]

I had this experience recently. My company was looking to implement a computer-based training system for the employees at my plant. The HR department checked with other plants and found that they all used the same vendor as part of one giant training system. This system was decent, but the company charged an arm and a leg for everything. As the IT guy, I looked into some alternatives, and I found a couple of SCORM-compliant open source LMS packages. The only drawback to those is that we would have to put together our own content.

I put together one of these systems in a virtual machine, created a test course, and wrote up the expected project cost including an intern or two to create the training materials. I presented this to the project manager thinking that the management would appreciate something that could lower the expected project costs by $10,000 or more.

Instead...the idea was turned down because "I was the only one there to support it." I brought up cross-training someone in our plant or at a higher level of the company, and that was turned down because everyone was too busy.

What I don't get is why management doesn't trust their own staff. They hire us as computing professionals, so why don't they trust us to maintain systems that they want to lower costs or improve business.