Choosing an Open Source Vendor and Service Provider

Introduction

Notwithstanding the community-oriented spirit of open source, many user organizations prefer to use products that have commercial entities associated with them.

Why would a company choose to work with commercial providers rather than relying on the product community?

Here are a few reasons:

• Unfamiliarity with the open source ecosystem. If an organization is new to open source, it may prefer to stick with its established practices and partner with a commercial provider. Most organizations find the concept of open source community difficult to grasp at first, so this motive is very understandable.
  
  
• Lack of familiarity with the product. If an organization is just beginning to use a product and doesn't have anyone on staff very familiar with how the product works, it may be important to have experienced resources available. These resources may be part of the development team employed by the vendor, or may be a service provider that specializes in the product. Either way, the company addresses a weakness in its talent set.
  
  
• Desire for legal protection. Some open source vendors provide indemnification to their customers. This indemnification promises to defend the using organization should anyone bring suit against it for intellectual property infringement.
  
  
• Desire to influence the product team. Engaging in a commercial transaction with the vendor is a sure way of helping it understand customer requirements; if the product is an important part of the user's IT infrastructure, it may be worthwhile investing some budget in the hopes of getting the product improved in ways that are helpful.

However, all of these reasons make sense only if the vendor or service provider is a good partner. Before entering into a commercial relationship, what are the things you should look for to determine whether it makes sense? First let's discuss what you need from an open source software provider, and then turn to what you need from a service provider.

Five Things to Learn about an Open Source Software Provider

1. Do they provide the services you need? It's not enough that there is a vendor associated with the product you're interested in. What's really important is that they deliver what you need. If you are looking for architectural advice to help you understand how to integrate the new product into your infrastructure, and the vendor focuses on technical support for their product, you're not getting what you need. Be sure to define what you require from the vendor and confirm that it's available.
   
   
2. Do they provide good value for your investment? Unfortunately, some vendors bundle their offerings—so support comes along with indemnification even if you only need on-call technical support. Don't overbuy what you need. Also, try and estimate how much service you'll need. Many organizations purchase much more support availability (in other words, more hours than they truly require) than necessary. It will be difficult to calculate at first— after all, if it's a new product to you, how do you know how much help you'll need? However, after a year of use you'll have a much better handle on how much service you require—and how much you should buy.
   
   
3. Will they grow as your use of the product grows? Some of the vendors that have sprung up around open source products are quite small. Oftentimes, a couple of members of the product's development team start a company to capitalize on its growing popularity. There's nothing wrong with that—in fact, it is a huge benefit that the company you contract with, has actual developers providing service. On the other hand, as your use of the product grows, you'll probably require more sophisticated services: architectural advice, twenty-four hour support convenient for any time zone, perhaps multilingual services. Try and determine if your potential needs fit with the ambition of the vendor. If it likes staying small while you're thinking big, it could be a problem down the road.
   
   
4. Are they part of an active community? As open source usage has grown, so has the number of open source vendors. Most of these companies have grown organically out of the product community as discussed just above. However, some companies are now deliberately trying to take advantage of open source's easy distribution to create markets for commercial products. In other words, they're taking the old proprietary model and grafting on an open source license in the hopes of acquiring customers at a lower cost. As a user, committing to a product from one of these new-style vendors poses a problem. Without a lively product community, you're vulnerable to the provider with no viable alternative for help or support. Confirm that there's a community associated with the product, not just a vendor.
   
   
5. The last thing to think about an open source vendor is more about you than the vendor itself. Keep your expectations about a vendor realistic, especially during the sales process. Without a license fee to fund sales and marketing activities, many of these companies offer far fewer pre-sales efforts. Many of them have rudimentary web sites, Often they will refuse to respond to RFPs. If you're used to dealing with proprietary software vendors, where it seems like you can't shake them off your ankle, this can be quite a shock. Don't be surprised— it's nothing personal. It just reflects the less costly business model.

Five Things to Learn About an Open Source Service Provider

What if you're looking for some consulting help rather than support services? Are there other things you should be thinking about when engaging an open source service provider? Here are the questions to ask when looking for help from a service provider.

1. Are they committed to open source? If the provider you're considering does open source as a sideline, there could be trouble. They may try to steer you toward another solution based on their needs, not yours. Beyond that, if you're looking to another entity to help you with your open source issues, you want them to understand the open source ropes—license implications, how to interact with the community, even (perhaps) how to submit bug-fixes. They need to be an expert at the new world of open source, not a company that dabbles in it.
   
   
2. Do they have expertise with your product? It's not enough that your service provider is enthusiastic and experienced with open source. They also need to have expertise with the product you're using. Confirm that they know what they're doing with it.
   
   
3. Do they play an active role in the community? The concept of community runs through open source. The community is a key resource for training, support, and moral support. Working with a firm that can turn to other community members is a major benefit for you, because a community-involved provider can solve your problems more quickly. Ask the firm if they are regularly participating in the product forums.
   
   
4. Do they have a relationship with the commercial provider, if one exists? If the product is sponsored by a commercial vendor, it's vital that your service provider know and be known by the vendor. It's simple, really—you want the provider you're depending on to be able to communicate your needs and get your problems addressed. This is much easier when your provider has a preexisting relationship with the company. The message of this question and the previous one is straightforward—the more involved your service provider is with the product ecosystem, the better off you'll be.
   
   
5. Does their style fit yours? Just as many of the open source software vendors are unpolished, so too are many open source service providers. Many of them were started by highly technical individuals who know the ins and outs of the product. They're fantastic at fixing a problem, but may not have the experience or temperament for many aspects of your project, like documentation, project schedules, and so on. Depending upon the way you like to work, some firms may be better partners than others. Outline the way your company does things and check whether they will be responsive. If the consulting firm doesn't seem like it's ready to cooperate, don't hesitate to walk away. Better to realize it won't work early, rather than halfway through the project.

Takeaways

As more companies begin to use open source, demand for direct support and services beyond those available on-line via the community will grow. If you're a company looking for open source help, look beyond the surface to ensure you're getting what you need. Spending a little time asking questions up front can avoid problems down the road.

About the Author

Bernard Golden is chief executive officer of Navica, a consulting firm offering open source strategy, implementation, and training services. Golden is a well-known authority on open source, particularly regarding enterprise adoption and use of open source. He writes a regular column on open source software for CIO Magazine, and is the author of Succeeding with Open Source (Addison-Wesley, 2005), as well as the forthcoming Open Source Best Practices. Contact him at bgolden@navicasoft.com or visit the Navica web site at www.navicasoft.com.