The Quandary over Open Source Support

If you’re like a lot of IT organizations, you’ve got servers from Hewlett-Packard, routers from Cisco, operating systems from Red Hat and Microsoft – and you may even have Solaris from Sun somewhere. For good measure let’s throw in a few databases from MySQL that occasionally take a virtual table or two from your SQL Server farms – and let’s not forget to mention the Oracle database that runs your CRM software. To top things off you’re running a slew of other open and closed source software that all together keeps your business running.

Welcome to the current state of IT. So here’s the question – how many people know your entire topology and can support all that stuff? Most likely you don’t have one team that understands the way you do business. More likely, you have a handful of internal and external teams for each application. That makes you especially dependent on the support you get from your vendors.

Software companies, especially open source ones, live on support contracts. That’s a fact. But another fact that is almost never talked about open source software vendors is that they almost never support the stack environment that their product runs on.

Let’s say you’ve got a problem with your database (choose one – you have so many!), and you contact that support specialist about locking or some other issue about performance; you’ve spent about two weeks with them in a few hundred ticket updates. We’ll, I’ve got news for you. Once they figure out that they have no idea what’s wrong, they are most likely going to pass the buck to either server software or scripting software that their products depend on, or hardware products that they are running -- “You’re running our software on a 32-bit processor and we require a 64-bit processor." Never mind the fact that you called about something that has nothing to do with processors.

Too many managers fall for the notion that open source is cheap. Well, it’s not cheap at all when you have to hire three support vendors for the application, the OS and middleware systems it runs on, and the underlying hardware. That brings me to the point of my story -- where is the support for the technologies underlying the open source code?

I would love to replace my proprietary licensed Web site content management systems with an open source equivalent (I hear Joomla and Drupal are really good). Without a support team that can diagnose and fix not only the problems in their software but also in anything else (including hardware issues) that may be affecting it, I’m going to go with a full service proprietary company.

As with most IT departments, the choice of support is one of return on investment. You really do want to retain your IT knowledgebase to inside your own walls. But the need augment that talent with holistic support is non-negotiable for today’s business.

So to open source projects and vendors out there, if you’re listening, lend me your ear and give me some support for the entire stack!

Comments

I stick to my point that it is tougher to find an all inclusive vendor that supports the stack when you start to combine proprietary and open source technologies. I do believe it's up to the Open Source vendors to fill in the gap and Jesse and Alex represent vendors who are filling the vacuum left by this need. Did I say it's easy? Nope -- and it's not. But there is money to be made in this support model and open markets will decide winners from losers. I speak to many CTO's and CIO's and this is a major issue for them (even if it is an assumed issue - they may mean some education is needed). I saw some people say that they take care of it all. Well you tell that to a CTO of a mid to large company and they'll cringe. The last thing you want is one person that is taking care of everything. A few times I've run into this with vendors that did a perfect job until someone on their team left and it turned out that they were the only person on their team that knew our environment. Jack of all trades are dangerous in the 1000 mile view of things. OSS has a lot of zealotry and most cases a great community, but there is a big difference between taking a hobby project and bringing it to enterprise level -- part of which is to ramp up the support options which must include supporting other "stuff" because quite frankly OSS is the one hitting those hedge barriers not the MS, Oracle, or Sun's of the world which are fully entrenched.
I stick to my point that it is tougher to find an all inclusive vendor that supports the stack wen you start to combine proprietary and open source technologies. I do believe it's up to the Open Source vendors to fill in the gap and Jesse and Alex represent vendors who are filling the vacuum left by this need. Did I say it's easy? Nope -- and it's not. But there is money to be made in this support model and open markets will decide winners from losers. I speak to many CTO's and CIO's and this is a major issue for them (even if it is an assumed issue - they may mean some education is needed). I saw some people say that they take care of it all. Well you tell that to a CTO of a mid to large company and they'll cringe. The last thing you want is one person that is taking care of everything. A few times I've run into this with vendors that did a perfect job until someone on their team left and it turned out that they were the only person on their team that knew our environment. Jack of all trades are dangerous in the 1000 mile view of things. OSS has a lot of zealotry and most cases a great community, but there is a big difference between taking a hobby project and bringing it to enterprise level -- part of which is to ramp up the support options which must include supporting other "stuff" because quite frankly OSS is the one hitting those hedge barriers not the MS, Oracle, or Sun's of the world which are fully entrenched.
I think the problem here is because you are thinking "product" and not "service". Your ultimate goal should be to offer a service to your users or to your clients, not buy products. So the same way, if you buy products and not services, your not buying the right thing. You should never buy a support contract for a product, but you should buy service contract for the technologies that you use. A lot of compagnies tend to offer support only for a product because it's easy.. you can always blame someone else and it's easy to learn only one product. But there a compagnies like ours that will support your entire stack. It's a lot more work and you can't just ask for quote, you have to build a relationship. And it works. We support a lots of governments agency and compagnies this way and they enjoy all the benefits of opensource software like being able to adapt fast, being in control or their technologies, being able to choose when they want to upgrade. Only these three benefits are so big that our client just laugh when they see that it cost less too. So just change how you see your IT and everything will begin to work well, whenever you are using proprietary or open source software.
-- It's impressive that open source, with or without external support, frequently offers at least a competitive bid, today. The reason this might be surprising despite all the benefits of low-cost licensing, transparency, competition, and flexibility is that open source has not yet established itself fully in an industry environment that has been dominated by closed source software for many years. As open source continues to grow, so too will the options. -- Another phenomenon of open source is that, just as many are willing to give top-notch coding (on their terms) for $0, so too many are willing to give a level of support for $0 if it's on their terms. There are great communities and these are growing. The key is to adjust expectations. Go in humbly. Help yourself as well (and, even better, find a way to leave something positive behind), and you might just be surprised at what you can accomplish or whom you will find. Leverage the access to extra information and friends to help push yourself a little more to learn more about your own needs and gain control for your self/company/etc. -- The future involves more and more open source because it's too powerful a model. For example, we will see many more open source companies focus on customizations in addition to support. Many students will come out of school not only sort of knowing theory but knowing various bodies of open source that they will be able to exploit no matter where their careers take them. We will see many more customers employ or contract groups already knowledgeable with the majority of the products being used. -- Those businesses that quickest find a way to leverage open source will gain in the market place ahead of the pack. -- This article makes some fine points and states that the ball is in the court for open source companies.
Joseff, support is not an issue and I don't agree with the thrust of your story. All IT Departments should document their installations, whether Open Source or not. All you need is an Apache server and a copy of SeaMonkey. It takes a morning to document a server and/or application, complete with storage partitioning and layout diagrams. The point I would like to emphasise is that Free Software operating systems and applications do exactly what they claim to do. The only real requirement that an IT bod requires is the ability (and preparedness) to read the README and INSTALL notes. There is absolutely no need whatsoever for outside or third party support.
Perhaps I missed several points here, but this seems like the classic management conundrum -- I want more for less. How do I do that with IT support? Answer: You cannot, unless the region your business operates in has a lower standard of living or you're willing to outsource to a location that has a lower cost of living. That's why India and China continue to win IT support business contracts. The amount you pay (internal or external) personnel to perform IT support is directly proportional to their expertise. If your business demands "people know your entire topology and can support all that stuff", then you're going to pay them accordingly. As for this question: "where is the support for the technologies underlying the open source code?" You simply need to look harder and/or pay more. The reason for this is because open source support has not historically paid well, but that's changing. There's a certain irony here -- the original developers did this because they wanted to and were willing to do this at a lower wage (initially at no cost) because it gave them control. However, as businesses demanded more control and these developers wised up, things began changing. Costs have steadily risen as a result. As for this point: "Too many managers fall for the notion that open source is cheap." You get more with open source. Freedom from licensing audits, the access to source code and associated freedom to change suppliers, and the ability to participate in meaningful user communities. That means you as a customer can be more than a "user" if you choose. The problem is that businesses choose not to be more than users. These additional benefits are not valued and open source appears about as costly as proprietary vendors. So it's not a question of cost, but of values. Most businesses simply don't value the additional benefits that open source provides. If they did, open source would indeed be "cheaper".
Perhaps I missed several points here, but this seems like the classic management conundrum -- I want more for less. How do I do that with IT support? Answer: You cannot, unless the region your business operates in has a lower standard of living or you're willing to outsource to a location that has a lower cost of living. That's why India and China continue to win IT support business contracts. The amount you pay (internal or external) personnel to perform IT support is directly proportional to their expertise. If your business demands "people know your entire topology and can support all that stuff", then you're going to pay them accordingly. As for this question: "where is the support for the technologies underlying the open source code?" You simply need to look harder and/or pay more. The reason for this is because open source support has not historically paid well, but that's changing. There's a certain irony here -- the original developers did this because they wanted to and were willing to do this at a lower wage (initially at no cost) because it gave them control. However, as businesses demanded more control and these developers wised up, things began changing. Costs have steadily risen as a result. As for this point: "Too many managers fall for the notion that open source is cheap." You get more with open source. Freedom from licensing audits, the access to source code and associated freedom to change suppliers, and the ability to participate in meaningful user communities. That means you as a customer can be more than a "user" if you choose. The problem is that businesses choose not to be more than users. These additional benefits are not valued and open source appears about as costly as proprietary vendors. So it's not a question of cost, but of values. Most businesses simply don't value the additional benefits that open source provides. If they did, open source would indeed be "cheaper".
Perhaps I missed several points here, but this seems like the classic management conundrum -- I want more for less. How do I do that with IT support? Answer: You cannot, unless the region your business operates in has a lower standard of living or you're willing to outsource to a location that has a lower cost of living. That's why India and China continue to win IT support business contracts. The amount you pay (internal or external) personnel to perform IT support is directly proportional to their expertise. If your business demands "people know your entire topology and can support all that stuff", then you're going to pay them accordingly. As for this question: "where is the support for the technologies underlying the open source code?" You simply need to look harder and/or pay more. The reason for this is because open source support has not historically paid well, but that's changing. There's a certain irony here -- the original developers did this because they wanted to and were willing to do this at a lower wage (initially at no cost) because it gave them control. However, as businesses demanded more control and these developers wised up, things began changing. Costs have steadily risen as a result. As for this point: "Too many managers fall for the notion that open source is cheap." You get more with open source. Freedom from licensing audits, the access to source code and associated freedom to change suppliers, and the ability to participate in meaningful user communities. That means you as a customer can be more than a "user" if you choose. The problem is that businesses choose not to be more than users. These additional benefits are not valued and open source appears about as costly as proprietary vendors. So it's not a question of cost, but of values. Most businesses simply don't value the additional benefits that open source provides. If they did, open source would indeed be "cheaper".
I recently was hired by an outfit that had tried to run IT totally out-sourced. Every user in the building had Administrator access. The router was wide open. Half the machines were unusable. The LAN had 10baseT equipment. We are going to a FLOSS stack ASAP because the costs and problems of administering it are much less and we can use all our existing equipment indefinitely. With a tiny hit on the budget once we can bring all the software and networking up to speed quickly and manage it locally or out-sourced as we need. A demonstration project amazed folks who had no idea what good IT looked like. We would need a half-dozen vendors on the phone to support us using wintel. One-stop shopping is much more efficient. One employee is all that is needed to manage everything here. For us, simplicity beats complexity and obscurity at any cost. That adequate support is available for the cost of searching with Google, is a big bonus. With GNU/Linux, the support issues tend to arise upon change. Once configured, systems run indefinitely. Before, systems ran a few weeks before deteriorating. On top of that we see huge increases in performance: faster booting, faster response to clicks, and local web apps instead of remote are several times faster, and no malware. We see no downside to FLOSS at all except a small cost at switchover which is repaid instantly by improved performance.
Personally I think open source is superiour to a Microsoft GUI based environment, because you at least have the option to look deeper into the system inertia. However, the opposite might also be true. The author here writes about commercial support with report-and-forget tickets. This is not something you will get with either, all-open-source or all-proprietary software. Sometimes problems are hard to diagnose. If internal IT support can't find the error some IT shops want to just dump their problems onto external support contractors. Externals often don't know enough about the internal system customizations or just don't have the access to diagnose errors. So, the attitude to "just" getting something solved doesn't work in the real world. Only knowledgeable internal IT can solve the complex issues, and often this is only possible of the full source is available. In the case of CRM software, it's often just stuff within the database, so the proprietary vendor might be able to solve it all by itself. In my shop, it's hardly that way however, because dozens of other systems have been hacked in. Too little insight into the inner system workings left, so often its better to just recreate customer accounts. We also have a new proxy setup, where the thing suddenly stops working for some users. Instead of diagnosing the bug, the highly-skilled expert from that proprietary vendor just told us to reinstall all Windows PCs where that problem occours (10 per week, go figure).
The good thing about OSS is that thee source is available to everyone; including third party support companies and consultants. I work as a consultant for a number of SMBs (or SMEs in some countries) and I provide full support from sourcing hardware, networking, OSes, middleware and application software. If a power supply dies I replace it, if the OS does something wonky I fix it. I have even gone to the level of writing kernel patches to fix client's problems, something you can't do with closed source software. Whenever a client asks for a secure set up most of the time I recommend running Linux on the desktop because you can configure it to be more secure; and if that fails you can always patch the software. And last of all one of the reasons my clients prefer OSS is no more CALs...
If you get support from someone who sold you the CRM, and he is not M$, you are in big troubles, because they can't support the underlaying stack (they don't have the source code, they can't analize and debug). M$ on the other end will tell you that is just a CRM problem, their OS works so well that everyone is using it, and you are the only one reporting this problem... So the only sane thing a company can do is use only Free Software, that you can have support from multiple sources, and if you are in serious troubles and find yourself in a desperate situation, you have all the source code to analyze and debug. With proprietary software you are on the mercy of the software producer, that can not be the best support, or could be no interested at all in finding what your troubles are.
Business is still adopting LAMP stacks in big ways. Regardless of the paid for 'studies' that get trotted out (which are nothing more than marketing fluff), the bottom line is that LAMP works better, costs less and actually has better free support than the expensive proprietary stacks do. Believe it or not, a lot of businesses are even running 'unsupported' things like CentOS, etc., and choosing to pocket the savings and gamble that they might have to pay some consulting fees if and when they have some kind of problem. In practice that almost never happens, and the savings of not paying for a virtual protection racket adds up pretty quickly.
I got news for you: MS isn't much different. I've been working on a bank where there was a serious problem with an MS stack. We spend some serious time with these MS engineers to figure out what was wrong. You know what? They couldn't figure it out as well. We paid some serious money for their "support". The problem is that the current stacks are so complex that you can run into some very complex problems. On the other hand, I've been working a lot with FOSS products. They run and keep on running until the hardware says pfff..! Not like these MS-servers that require rebooting for some serious memory leaks.. when they come up at all. When there was a forced powerdown, we had to shut all these machines down in a controlled way and boot them up again when the problem was over. A significant number of MS-servers failed to boot, causing significant damage - and loss of business. So stop trying to feed the people in the field this SOFUD. It doesn't help your credibility.
So basically what you are saying is that because the LAMP stack consist of 4 parts, the support costs of it will always exceed the support costs of the for ex Microsoft solution? Interesting. Have you given these points a thought: First of all, you don' t have to sign separate support contracts for your LAMP stack. Just look at the two first reactions you got here. Second of all, if the reliability of the 4 separate LAMP components is greater then your single MSFT stack, the support costs will be lower as well. Third, the LAMP stack mostly has community support for all the separate pieces. Not because you are "a company" means that the only support you can get is the support you've paid for. Forth, not because you don't have to pay fees for the LAMP stack, means you should not make a solid architectural decision regarding the software your business will depend upon. Thanks Robert
I'm not sure how OpenLogic supports so many open source projects - no doubt very impressive. I work for Acquia, an open source company that supports Drupal. Although we don't provide stack support directly - we do provide a fully managed high availability hosting specific for Drupal. In this case, the customer doesn't need LAMP stack support because we take care of all the underlying open source technologies. This will also be a similar case with Drupal Gardens that will empower users to easily create micro sites. Similar to WordPress.com, but with many more features beyond just blogging. Going back to the article - its a very valid point. I believe open source companies will begin working closer together to solve the underlying issue. Perhaps this is what OpenLogic is doing, although I don't know too much about them. I'd be happy to discuss Drupal support or our managed hosting with anyone. Alex Lindahl alex@acquia.com
i work at openlogic, we provide commercial grade tech support for 500+ oss products (community versions only), now including CentOS to provide support for the entire LAMP stack, we are not platform specific and work with customers all the time on their mixed environment integration/configuration issues, we are currently working with our partners to establish remote monitoring and pro-active support for both open source software environments and some open source voip hardware, take the best of what springsource, redhat, the FUSE Community, palamida, black duck, etc... are offering and if we arent already doing it we will be there within 12 months, happy new year!

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
  • Allowed HTML tags: <b> <i>

More information about formatting options