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?
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.
http://www.openoffice.org/
Not sourceforge but it's so bloated there has to be an Air Traffic Control System in there somewhere.
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.
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.
Or, if you have decent communication skills, talk to the developers who can usually fix it very quickly. A few years ago, I was having trouble getting FreeTDS to compile on an *old* Solaris platform (not a common target in the least). I worked with the developers, James and Freddy, I think, and they were astonishingly responsive. In fact, at times I was the one slowing down the process. They had the bug investigated and patched in a day or two. Unbelievable. That could never have happened with closed-source software.
Another time I ran into a minor SQLAlchemy bug having to do with Postgres domains column types. I reported it along with some sample code to reproduce the error, and it was fixed in the next release a couple weeks later.
It's that kind of responsiveness that's the reason I'm a FOSS fanatic. I get so frustrated with closed off-the-shelf software! Yes, FOSS is sometimes a little rough around the edges or incomplete, but it's always improving and the authors have always been responsive to my problems -- even if it was a PEBKAC error. Can't say the same for closed source.