Community-Sourced Kuali OLE Serves Libraries

Key Takeaways

• The Kuali Foundation offers a lightweight administrative framework for developing new models for open source application development.
• Using this open, lightweight approach, Kuali OLE is developing software applications for a library management system for research libraries.
• In addition to the buy, borrow, or build options for developing local campus application solutions are open and community source software communities.
• The Kuali OLE hybrid strategy involves pooling community-provided investment funds to outsource software development with a commercial vendor and offering community support for quality assurance, release management, and implementation.

When the Kuali Foundation, at its founding in 2004, sought to deliver an open-source financial system for higher education, built by higher education, some institutional CFOs were skeptical. Concerns about the open-source approach focused on code quality, system reliability, and sustainability. Just five years later, an article in The Economist stated, "Open-source software has won the argument."¹

Between 2006 and 2010, six other projects formed under the Kuali umbrella: Kuali Coeus (for research administration), Kuali Student, Kuali Rice (shared services and middleware), Kuali Ready (SaaS for business continuity planning), Kuali People Management for the Enterprise (human resources and payroll), and — the subject of this article — Kuali Open Library Environment (OLE).

Open Source/Community Source

The not-for-profit Kuali Foundation promotes collaboration to develop and enhance enterprise software applications for higher education. The code base is delivered as open source under the Educational Community License 2.0. According to Wikipedia, open source "… describes practices in production and development that promote access to the end product's source materials. Some consider open source a philosophy, others consider it a pragmatic methodology. Opening the source code enabled a self-enhancing diversity of production models, communication paths, and interactive communities." What distinguishes Kuali from other open-source communities is the way the software is designed, developed, tested, maintained, and enhanced.

The Kuali community built a model in which development work was assigned to vetted communities of developers tendered by project partners. This ensured that while the community dictated priorities, code was vetted through a known and tested methodology, with an identified community overseeing the development. Community source is a blended model, combining the openness of earlier open-source projects and elements of directed development whereby institutions contribute human or capital resources.

The model does more than reduce risk. Partner schools share the functional specifications and the knowledge base about the technology stack. Institutions also enjoy lower implementation costs because developers are involved up front. Commercial partners provide services around the software, creating a competitive marketplace. Brad Wheeler, vice president for information technology and CIO at Indiana University (and Kuali Foundation board chair), suggested that community source can be understood as a hybrid model of a community, proposing "The Pub…the Place Between the Cathedral and the Bazaar" where higher education can really solve its [enterprise software] challenges."³ Wheeler recently demonstrated the model's impact in a presentation showing how it has changed the game and driven the concept of scale and collaboration.

Higher education historically has looked at strategies of buy, borrow, or build for developing application solutions within a local campus context.⁴ A collaborative environment, using a community approach, creates choice in delivering enterprise systems to higher education. Numerous community source and open-source software communities work on applications for institutional repositories and learning management systems, but how do you enable above-campus software development and hosting to support common community needs?

The Kuali Foundation's answer was to offer a lightweight administrative framework to develop new models for application development and hosting for functional communities within higher education. The OLE Project Team is using this approach to develop software applications for a library management system for research libraries. This means pooling shared funds to outsource development of software with a commercial vendor, as well as offering shared community support for quality assurance, release management, and implementation.

Launching the Community Source Concept

Kuali was founded on the idea that leveraging resources across many institutions to build systems would save money. Kuali would incorporate best practices for higher education and offer institutions an alternative to building their own systems (a costly duplication of effort) or buying vended systems (often entailing significant ongoing licensing costs and failing to meet higher education's needs).

Along with the primary goal of delivering software, the Kuali Foundation sought to create options for the marketplace to offer related services competitively and avoid the single-vendor model with its monopolistic pricing scheme. To that end, the foundation encouraged commercial partners to join the community; currently Kuali has nine commercial affiliates.

The first full production implementation of a complete Kuali system was the Kuali Financial System (KFS) at Colorado State University. Implementations have grown significantly during succeeding years. Commercial partners are supporting many of these implementations. In addition, Kuali Ready SaaS has 64 subscribers.

Open Library Environment Extends the Model

In early 2009, the OLE Project came to the Kuali Foundation to discuss a potential partnership. The project had been under way since spring 2008, developing its investment and specification community. Both parties eventually agreed that including OLE under the Kuali umbrella would be a winning partnership.

But first, OLE leadership carefully considered whether a tendered resources model would work for this project. Most library technology offices lack staff expertise in Java software development. Given the aggressive timeline for OLE deliverables, project leadership advocated hiring an experienced software development team. The rest of the Kuali model would remain intact. Functional experts would prepare the specifications and set the priorities. The OLE Project Team would manage quality assurance, but development itself would be contracted to a vendor, allowing time for the library partners to develop the needed software skill sets in a just-in-time fashion for system implementation.

Robert McDonald, Kuali executive director, explains the strategy for working with a vendor:

The Kuali Foundation sees its strengths as pragmatism and flexibility across projects. The only immutable attributes are:

• Licensing
• Handling and management of funds
• Reporting to external regulatory agencies

So it was not a stretch to embrace this alternative approach to meet the needs of the OLE investment partner community.

Finding the Right Partners

In the early stages it was important to establish a business partnership with investing partners that was agile and at the same time poised for long-term sustainability. OLE needed a large group of community members involved in the planning and design phases in order to identify the initial nine investing libraries that enabled Kuali OLE to form the charter by which it joined the Kuali Foundation.

Developing the charter with the Kuali Foundation as an affiliated software application development group provided a key financial backbone for creating a long-term sustainability model. This charter clearly states the broader outlines of how the OLE partners will work together over the initial build phase and will serve as a resource document for developing the partnership over the long term.

A key factor that drew the OLE investing partners to the Kuali Foundation was the emphasis on lightweight administrative overhead, community sustainability, and the community-driven software model. The core group of partners supports the efforts at collaboration for a minimum 10-year timescale. Kuali OLE's life cycle (2012–2022) is intended to maximize its return on investment. Committing to this life cycle for application development forced the OLE team to think beyond short-term planning. Often the success or failure of an open application development depends on achieving the long-term support necessary to sustain the project.

An important lesson learned from planning and implementing the Kuali OLE Project is that:

You must build community first to establish sustained collaboration at an above-campus level.

Financial Support

Kuali OLE received Andrew W. Mellon Foundation funding to study its community for a year (2008–2009) to understand the needs and help identify the working partners that would become part of the design and build phases.⁴ This let the OLE Project Team move forward from the needs/community assessment phase into the build/investment phase.

But Kuali OLE also needed financial support from its community. Early in the planning phase, the OLE team knew they needed firm financial commitments before moving into the build phase. This focus on long-term planning and sustainability paid off, although it took nearly six months of negotiations among partners to make the investing group lighter and nimbler. From more than 300 international institutions in the community phase the group slimmed down to nine investment partner institutions located strictly within the United States. Finding this level of trust and investment made it easier for the partners to discuss larger issues concerning both funding and governance.

Robert McDonald explains the strategy behind Kuali OLE partnerships:

Borrowing Elements

Another key component of our community partnership was looking at existing software that might be used in Kuali OLE application development. Several open-source library management systems were available from the start (Evergreen, Koha), and these were evaluated at length for their strengths and weaknesses so as not to spend time later reinventing the wheel. Unfortunately, the existing software did not use a true services-oriented architecture or a consistent middleware, and there were no plans for those systems to develop such components at the time. This was critical to the design path and made the team look further afield than just at the Kuali Foundation Enterprise Middleware (Rice), turning its attention to other OSGi (Open Services Gateway initiative) implementation models such as Mule ESB or Open ESB. In the end, what sold the OLE team on Kuali Rice was higher education's abundant experience with this middleware and the flexibility it showed for scaling both up and down for workflow operations.

What to Build and How to Build It Together

After assessing the strengths of software that could be adapted or used within the build phase, the OLE team set about defining the framework needed to build the software (July 2010–November 2010). Five initial groups were formed out of the Kuali OLE Functional Council. (This voting member council is part of the governance group and oversees the software's functional specifications.) These five groups individually took up the issues of workflow, user stories, Kuali Financial System (KFS) fit/gap analysis, data model, and communications.

Within two months the groups were analyzing KFS to:

• Understand which components might be useful for Kuali OLE
• Start developing and parsing the functional user stories for use in deriving the overall functional requirements
• Study the existing workflow in the library acquisition supply chain to look for redundancies and streamlined models for use
• Construct an initial data model based on the user story analysis
• Create a core team for distributing communications about the overall project

These groups — in particular the user stories team — determined how many existing components of KFS and Kuali Rice were usable for OLE. This helped the team and the eventual commercial software vendor stake out what still needed to be written to support the functional requirements.

The OLE model revealed various pros and cons of hiring a contractor to handle development, as follows.

Pros:

• Vendor staff can ramp up more quickly because they already have skilled resources.
• The development cycle's peaks and valleys are easier to handle because vendors have an economy of scale in their resource pool.
• The OLE model avoids the issue of turnover and gaps in tendered resources supplied by institutions (the latter is not uncommon).
• The project manager spends less time vetting staff from schools for particular roles.

Cons:

• Institutions can be in danger of not being able to build a knowledge base and a network of individuals who understand the system.
• Because partner schools are acquiring less knowledge during development, implementation costs might be more expensive than in other Kuali models.
• Oversight of developers' work might be more difficult because coding is done by a pool of developers in a contractor firm rather than by colleagues at partner institutions.
• Developers miss the professional growth opportunity of being part of a large collaborative project.

Finding the Right Commercial Partner

Kuali OLE had to find a long-term partner who specialized in Java development, understood the needs of higher education institutions, and understood the long-term as well as the shorter-term aspects to winning the OLE contract. Indiana University Purchasing managed the overall RFP, although the OLE review panel searched more broadly. Core team members were brought in from Duke University, the University of Pennsylvania, and Indiana University, along with consultants from within the Kuali Foundation community. A wealth of bids helped identify three or four commercial vendors to bring to campus for in-depth discussions. Each vendor had many compelling reasons why they should get the contract, but in the end the winner, HTC Global Services, had three key components that made the firm stand out: a long-term interest in open-source solutions for higher education ERP systems, a background in building software for the publishing industry, and the capability to have onsite management at one of the investing institutions. These factors, combined with the ability to meet Kuali OLE's budget needs, made HTC the best choice as a software development partner.⁵

The RFP process identified several major components of the vendor contract that should be considered when utilizing a software sourcing contract such as the one described here by OLE.

Software Sourcing Contract Considerations:

• Core business. For Kuali OLE that business needed to be Java-based software development and integration.
• Scaling capabilities. Could the vendor scale to meet all requirements of the initial OLE build proposal? If not, in what timeframe could they scale to meet those needs?
• Familiarity with customer business model, software, tools, and approaches. These elements are critical, as they will require more time on the part of the contract holder if the vendor has less experience with these functionally specific components.
• Management techniques. Having multiple options for management of the development team was vital for OLE because this entire approach was an unknown at the time; having multiple options that included alternate strategies for success were key components in this metric.
• Transparent costing. If details are unclear, be able to ask a vendor about costs, profits, and the overall relationship.
• Mitigation of time differences between staffs. If the vendor's staff works in a different time zone, how will the two staffs communicate effectively for ultimate success of the project?
• On-site project management. Does the contract cover provision of on-site management of the project?
• Travel and training for the outsourced team. Does the contract cover these options?
• Past experience. Does the vendor have experience with pertinent projects and delivering solutions? Was the vendor willing to follow up with those customers if needed?

Building Expertise Locally and Scaling to Sustainability

At its core, the Kuali OLE Project depends on building software expertise with each local investing partner while simultaneously scaling down the amount of effort expended by the commercial vendor. This will lead toward affordable sustainability for the investing partners. After the initial 10-year life cycle, the board will decide whether to target investment for a technology stack overhaul or to gracefully terminate the project. In essence, the two-year initial build phase will let OLE ramp up skill sets for Java programming and configuration while gaining configuration skills for using Kuali Rice services. Each investing partner must work locally to develop these skill sets so that their investment in Kuali OLE eventually transitions from an all-cash investment to one that is more leveraged to FTE-based skill sets and minimal cash investment for project sustainability.

Mike Winkler explains the planned development of skill sets at the University of Pennsylvania:

Future Projects

Kuali now has two effective development models: using tendered resources from partner schools, and aggregating cash from partner schools to buy development resources from one or more contractors. Other Kuali project developers are evaluating these models. Two projects under the KFS umbrella have chosen the contractor model. The hybrid Kuali Coeus sustainment model incorporates both approaches.

Asking the following questions can help in selecting the best-fit model for future projects:

• How robust is the partner institutions' development pool?
• How will the project withstand resource turnovers that could affect scope and timeline?
• How important is it for the partners to buy down costs?
• How important is the Kuali model's professional development aspect?

Each project team will determine the model that works best for its community. Kuali's flexibility suggests that other models could evolve beyond the two described here.

Sharing Globally

The Kuali OLE model makes it easier to scope software and get it out on time and within budget. For the development cycle, the OLE team must please only the investment partners, so concepts like scope and deliverables are much clearer for the initial round of development. However, others may derive value from the software or use it freely and openly. Kuali OLE is freely available to any library community under the Open Source Initiative's Educational Community License V 2.0.

As Kuali OLE moves toward long-term sustainability, the OLE collaborative seeks new partners who want to benefit from OLE's shared resources including community support for software migration and for software quality assurance and continuous integration. An annual community conference (Kuali Days) is a resource for finding support and solutions among implementing libraries and Kuali Commercial Affiliates. Community support comes as well from our committed implementation partners and Kuali application partners, such as the Kuali Rice and KFS communities.

1. "Unlocking the Cloud," The Economist (May 28, 2009).
2. Paul Walk quotes Brad Wheeler, "NSF Workshop on Cyberinfrastructure Software Sustainability," Ariadne, Issue 59 (April 2009); see also the Wikipedia definition of community source quoting Wheeler.
3. Brad Wheeler, "Aligning IT Strategy to Open Source, Partnering, and Web Services" (Research Bulletin 24, 2003) (Boulder, CO: EDUCAUSE Center for Analysis and Research, 2003).
4. See "The Open Library Environment Project Final Report," October 20, 2009.
5. Since the contract was awarded to HTC, the firm has become a Kuali Commercial Affiliate.

© 2011 Jennifer Foutty, Robert McDonald, Michael Winkler, and Bradley Skiles. The text of this EQ article is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 license.