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