Slashdot Mirror

← Back to Stories (view on slashdot.org)

The Benefits of 'Vendor-Free' Open Source IT

Posted by Zonk on from the keeping-the-consultants-out-the-cold dept.

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

15 of 111 comments (clear)

  1. Open Source != Free by metlin · · Score: 2, Interesting

    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.

    1. Re:Open Source != Free by hedwards · · Score: 3, Interesting

      The biggest difference is that it's hard to institute buyer lock in if the company can commission a plug in to export the files to a different software suite. It might be expensive, but usually not, and it is usually less expensive than sticking with a company or software package that is that expensive, that outdated or possibly that insecure. In many cases the software has already been written by somebody that has wanted to do the same thing anyways.

      That probably isn't as much of an issue for home users, but in a corporate environment the cost of lock in can be huge.

      And that's the case whether the software is paid for or not, as long as you've got the code, you have the option to overcome the lock in most cases.

      Which is why I generally use products like moneydance that can export as xml or products that use common standards like mp3 or even rtf. Looking forward to ODF though, that'll hopefully be much better than the rtfs have been.

    2. Re:Open Source != Free by _Sprocket_ · · Score: 3, Interesting

      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). Isn't The Fine Article saying exactly the opposite?

      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. In fact, in my environment, we have done exactly this. We've said "Hey [HARDWARE VENDOR] and [LINUX DISTRO VENDOR], we implemented [KERNEL HACKER]'s patch which has solved the stabilitly issue on [SERVER PRODUCT] - you guys should talk about getting this included in your next release." We've also said "Hey [SOLUTION VENDOR], we've made these code additions to [OSS PROJECT] you provided and its given us some functionality needed to solve some problems we've had - you should consider it in your next release." Granted - I don't see it every day. But it does come up.

      But that's all a bit of a red herring. It's not so important that we can make code changes but that other people can. People who aren't all beholden to the same decision makers. This gives us some leeway with our environment and vendor choices. We currently deploy a lot of RHEL. But if RedHat fails us as a vendor, we can move to Canonical or even Novell with relatively minimal fuss. We've put off major vendor and architecture changes like this before because the shift from one proprietary architecture to another was so dramatic that we were willing to put up with substandard vendor support for years. If that particular example was based on an OSS architecture, the shift would have been far, far simpler (albiet still somewhat involved I'm sure).

      To a lesser extent, licensing is still a plus. We have RHEL entitlements for our lab, but never enough to cover all the projects popping up. Most of the time we can simply stand up a CentOS instance and work with that until the point where one "needs" a full RHEL install. We really don't need the full support of RedHat for those projects. And it's nice to not worry about where the licensing is coming from.

      Do we still pay for Open Source Software? Sure do.... a fair amount. Of course, at our level, licensing is supposed to be a minor issue. I'd believe that more if we didn't keep running in to issues about where other OS installs are getting licenses or how many CALs a project needs.
    3. Re:Open Source != Free by symbolset · · Score: 3, Interesting

      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.

      The perspective that organic resources are inferior to external resources for solving problems can be resolved in HR by hiring capable people. You can start by hiring capable HR people or letting the prospective coworkers interview the applicants. If the attitude of the HR team is that any certified fool will do it should no surprise that certified fools are doing the work and the result will be as expected. If you can't solve this problem your competitors can and I'm not worried about how it works out for you.

      You're not just paying for support and stability. If stability were a critical factor you wouldn't be looking at Microsoft solutions at all. Their history on this issue is bad. Integration is a factor too and here Microsoft has the edge because their integration from bottom to top is superb. It's easy to integrate when you have no standard to adhere to. Open source answers are great for servers where one server does one job and you can strip out every other part. Where standards are present there's no reason not to go with open solutions. TCP/IP won, didn't it? On the desktop open source doesn't gain the end-to-end integration advantage until you're dealing with high levels of customization or large numbers of apps that don't work well together. Virtualization and application servers can be very helpful here. If what you need is an end-to-end answer today with the resources you have, the Microsoft answer can be an appealing choice.

      Two major problems with the Microsoft solutions are stability and flexibility. On flexibility, when you come to the point where the Microsoft solution just doesn't have the feature you want you'll find you're in a corner where the solution is beyond any answer. On stability they're improving but we're still a long way from "good". Another problem with flexibility is that if you move to a standards based approach you will find that the standards lag the practice and to compete you'll need people who can assess the merits of available technology despite lack of dominant standards. Such people are seldom cheap and often hard to find. It is my belief they are worth both the effort and the money.

      If by some chance you find yourself in an organization where a movement to adopt open source or standards is successfully met with "We can't do that, we're a Microsoft shop" my best guidance is to flee to the competitor that is not so impaired, or if it's a government shop, to lay low and solve the problems you have with the best available technology and let the conflict settle itself out.

      --
      Help stamp out iliturcy.
  2. Yup by Phaid · · Score: 4, Interesting

    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.

  3. Open Source by Z00L00K · · Score: 2, Interesting
    Open Source is used in businesses in packages that are well-known and known to be stable. They require little maintenance and has little or no support cost. Examples are the Apache web server, Eclipse development environment and BIND.

    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.
    1. Re:Open Source by badpazzword · · Score: 3, Interesting
      This is exactly what is going on in the gaming community I participate in. The game itself is Microsofted Open Source, but the authentication system is a proprietary solution which relies on a third-party obfuscation company.

      It so happens that Windows Vista isn't fully compatible with the game -- .net SP3 borks the authentication system. Its dev promptly looked for the problem, and of course the problem was found in the third-party obfuscation tool. He submitted a ticket and the community is waiting for a fix.

      It's been 40+ days since this issue has been found, targeted and reported, but Nothing Happens(TM). We're still waiting for the fix. The admins do not obviously want to release a non-obfuscated version of the .net authentication tool, nor they want to switch over another obfuscation company (and pay for another license). So people using Vista are currently forced to work around the problem by blocking updates and using .net uninstallers.

      Even Microsoft Research has contacted us with details regarding the trouble, but again there is nothing we can do to address it.

      Our community is having a 40+ days [partial] downtime, and there's nothing we can do, but wait and publish workarounds for a problem we didn't create.

      Not the kind of stuff that makes you all warm and fuzzy on relying on third parties, huh?

      --
      When ideas fail, words become very handy.
  4. Irony? by mangu · · Score: 2, Interesting

    Don't you find it funny that a paper about Open Source costs $4500?

  5. Re:Hmmm. by haruchai · · Score: 2, Interesting

    If a company has a support contract, it's not that easy to just bail on it.
      Some of those enterprise or government contracts are pretty tightly written.
      I just finished taking a course at HP and the instructor said that due to
      the large installed base of OpenVMS in the US Armed Forces, HP bowed
      to the existing requirement that VMS will NEVER be "sunset".

    --
    Pain is merely failure leaving the body
  6. Re:Model at this point.... by CrazedWalrus · · Score: 4, Interesting

    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.

  7. Re:Hmmm. by WindBourne · · Score: 3, Interesting

    The feds are treated different. I use to work at HP, and I can tell you that HP will not sunset that stuff because it is SOOOO profitable once active development stops . The reason is that active development has stopped so the team of 300 ppl is now done to 30 and then down to 3. But you typically have the same amount of money coming in. That is why HP likes to buy up old companies. The support dollars makes them worth a LOT. It is also why HP really did not jump on Linux at first. There will never be that opportunity for end of contracts. OpenVMS will be milked with just 10 coders on it, for the next 2-3 decades (your instructor snowed you).

    But SCO is a different matter. They are about to go under. Once a company goes chap 9 or 11, they are under no legal obligations to uphold these, except ones like the feds. BG is only re-opening this case because Vista is an absolute disaster for them. Otherwise, SCO would now be gone.

    --
    I prefer the "u" in honour as it seems to be missing these days.
  8. Re: No other services required = 20 percent by Anonymous Coward · · Score: 1, Interesting

    > replacing IE, Outlook, MS Office, and MSN messenger [on Windows] does some differences

    Actually, you're right, it makes a lot of difference, by cutting off attack paths for viruses and ad/spyware. Good point!

    > things I miss and/or have not found good free/opensouce solutions for:

    > antivirus (never liked AVG)

    It wouldn't surprise me if the Open Source antivirus products are weak. It's a question of motivation -- most developers would choose to be improving good software, to make it more virus-proof, rather than creating band-aids for Microsoft's mess.

    > book-keeping(small company, products,prices,inventory,payroll normal stuff)...

    There is a growing number of small business accounting solutions for Linux:

    See: Linux - Accounting Software

    The list includes some known names, such as Accpac, and Appgen.

    I've also heard good things about the Open Source project SQL-Ledger. Because it stores its data in an SQL database (such as PostgreSQL), you can create your own reports, using, for example, the OpenOffice Database tool. Or, because it's Open Source, you can get even more adventurous, and customize it for your business.

    > software for doing labels and stickers (haven't really looked)

    There is support in this area. See Printing Avery labels with Linux.

  9. IT support costs go down but auditing goes way up by Catalina588 · · Score: 1, Interesting
    The IT department savings doing support and maintenance of open source instead of using binaries may well be a false economy.

    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.

  10. Evidence by gnutoo · · Score: 2, Interesting

    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.

  11. Re:Model at this point.... by ckaminski · · Score: 2, Interesting

    I used to work for a place with a very technical product, and had 5+ year C++ programmers doing tech support. We were authorized with specific clients to push out patches developed by support techs for special circumstances or blatant errors without needing to go through the full QA and review cycle. It wasn't done very often, and since it was a database product we were very terrified to do it for fear of data corruption. Even if we never gave the patch to a customer, our work often ended up as the approved fix.

    Some fixes truly are simple, even if the problem is horrible.