Open Source | Feature
7 Questions to Ask Open Source Vendors
Open source vendors can save institutions money and resources, but it's important to ask the right questions up front to avoid surprises.
With their budgets under increasing pressure, many campus IT directors are considering open source projects for the first time. On the face of it, the savings can be significant. Commercial emergency-planning software can cost upward of six figures, for example, whereas the open source Kuali Ready might run as little as $15,000 per year when hosted by a consortium.
But it's important not to be seduced by the numbers alone. Especially for smaller institutions such as Hartnell College in Salinas, CA, tackling an open source project on their own can be dicey, says Matthew Coombs, vice president of information and technology resources. "We have very few IT resources," he explains. "We have two people to manage 2,000 desktops, one network administrator, one telecom person, one web person, and a few lab techs--that's it."
For Hartnell to consider open source solutions such as Kuali Financial System or the Sakai LMS, Coombs knows he would have to rely on one of the growing number of vendors, such as VivanTech, rSmart, or Unicon, that offer support and services around open source software.
For smaller schools, it's almost always less expensive to work with a vendor that can spread costs over many institutions than to hire personnel to run the software in-house. "But even larger schools with a lot of resources could benefit from an affiliate partner," adds Coombs, "because the companies have already done these implementations two or three times and have been through the learning curve themselves."
While these vendors can save institutions time, money, and resources, it's important for IT leaders to clarify exactly how the relationship will work and what's included in the service contract. Many of the issues that IT departments routinely hash out with proprietary software vendors apply in the open source market, too. Total cost of ownership and return on investment are probably the two biggest, but there are some questions unique to the open source arena that need to be answered as well. Before taking the plunge, make sure you have answers to the following seven questions.
1) Is there a rich ecosystem around the software?
UMassOnline, the online arm of the University of Massachusetts, uses vendor Unicon to host and support its Drupal open source content-management system. Patrick Masson, chief technology officer, says he always looks at the size and vitality of the community around a project before considering open source. "If I became displeased with Unicon, I could just go somewhere else," he says of the Drupal community, which consists of a host of active user groups as well as vendors. "If there are several different vendors in the space, I can change pretty easily."
For some open source solutions, the online community is so vibrant that resource-starved schools can often find the help they need for free. The WordPress blogging tool, used by Macaulay Honors College at the City University of New York as an LMS, is a good example. "We've found that if a question or an issue comes up, somebody within the larger user community has already found an answer," says Joseph Ugoretz, associate dean of teaching, learning, and technology.
Universities can also use an open source service provider to stand something up, and then migrate it in-house later without worrying about vendor lock-in. "It is a risk-mitigation approach," notes Masson.
2) What type of governance structure does the open source project utilize?
Implementing an enterprise system, be it open source or proprietary, is a major commitment. Given that, it's important to verify that any open source project has a stable governance structure built for the long haul. "There are many different types of governance, from complex committee structures to one despotic leader," says Gunnar Hellekson, chief technology strategist for the public sector for Red Hat, an open source vendor.
Like universities, Red Hat has to decide whether it will support a certain piece of open source software--often for as long as 10 years or more. "We look at the governance and activity level," adds Hellekson. "We are wary if there is only one leader rather than a diffuse leadership. That tends to increase the risk level."
3) How active is the vendor in the open source community?
Open source projects are living, changing products. Institutions should look for vendors that are plugged into the broader community and are active participants. Some vendors just pay the membership fee for access to the software and use the logo, but they don't contribute much back, notes Maggie McVay Lynch, chief academic officer at consulting firm Thanos Partners and chairman of the board of the Sakai Foundation. "Others are very active in the community, always contributing back code to improve the core product and participating on boards."
She cites rSmart as an example of a vendor that is very active in the Sakai community. "To me, that means they are plugged into the community, are part of the culture of that common core, and will have the latest information on bug fixes or latest releases."
McVay Lynch also notes that open source software changes more rapidly than vendor-driven software. In a relatively brief period, for example, there may be 25 new enhancements. Institutions should clarify with their vendor how they are going to deal with these enhancements. How much involvement will customers have in deciding which ones the vendor will offer, and how quickly will they be made available? Will the vendor share its timeline of development?
4) What are the licensing options, and what are the exit costs?
With any software, it's important to understand not just the entry costs, but the exit costs as well. How simple would it be to switch support vendors? The answer may be related to licensing issues, says Red Hat's Hellekson.
"Some open source software has a core kernel that is open source, but everything else about it is rather closed or proprietary," he explains. "This is called open core." The heart of the software is free, but the tools the vendor has built on top are all closed. This may diminish its value as open source. The key is to ascertain what is valuable to your organization. Some schools may want a particular set of functions and features, and don't care about having the flexibility to switch vendors.
The whole contract process is a little different, too. Open source separates the software license from the vendor contract, which is usually a subscription for services. This approach is often new to university legal and procurement teams, which may need some time to become acclimated. It becomes easier over time, however, because licenses are the same for different types of products.
5) How flexible is the vendor?
While exploring mobile-technology solutions last year, IT leaders at Villanova University (PA) looked at eight or nine solutions. One of their key criteria was flexibility, leading them eventually to choose the open source Kurogo platform from Modo Labs, which offers a modular approach.
"We originally signed up for their Mobile Campus offering, which has 10 to 12 modules," explains Joan Lesovitz, director of instructional technologies. "If we want more development or customization, we pay for it. For instance, we paid for the Courses module that integrates with learning management systems."
A key benefit of Kurogo being open source is that other groups on campus can use it to develop mobile modules of their own. "With proprietary software, the vendor would do that type of development itself and charge for it," notes Jennifer Pohlhaus, assistant director for multimedia technologies. "Some commercial vendors will even charge you for things like formatting changes. This felt more like Modo Labs was a partner in helping us get set up."
6) How engaged will the vendor be with university staff?
If your staff members are going to be working on improvements to the open source software, you may want a vendor that will support them and serve as an advocate for when they contribute patches to the community. Andrew McAllister, manager of academic computing for OCAD University, an art and design university in Toronto, says contributing to open source projects is an important element of staff development.
"It's an exciting learning opportunity that will provide staff members with a challenge," he notes. "This will be one of their opportunities to do interesting work. We like to get under the hood and do some development work. Of course, with that additional control comes additional responsibility."
Last year, OCAD switched from a homegrown LMS to Instructure's Canvas, and it has had a great experience so far, McAllister says. OCAD's developers can engage in a vibrant community on an IRC chat channel and get almost instantaneous responses from Instructure.
7) Which charges are additional?
Most open source vendors will give you a slick demo of how the software operates. When it's time to sign the annual subscription, however, study the contract closely to understand what actually comes with the vanilla product, advises Thanos' McVay Lynch.
If, for example, you expected that integration with your student information system would be included--only to find out it isn't--your institution might be on the hook for an additional $25,000. "It isn't that these vendors are being secretive," stresses McVay Lynch. "We come with certain conceptions of what is included when we purchase software, but this is a different realm."
It's advice echoed by Hartnell's Coombs, who urges IT leaders to figure out what they are not getting with the software and service agreement, and what kind of staff skills they will need. "You have to ask yourself: 'Is it important that we have a support number to call?'" he explains. "If the answer is yes, that might be an additional $30,000 to $50,000 per year in support charges. Even so, it's likely much cheaper than what you would be paying a commercial vendor."
