osls.ca

If It's Good Enough for NASA...

NASA invites open-source partners

A common refrain from the commercial software corner is that open source isn't good enough to cut it. I think the subject tag says it all :-)

Open::RFP - Opening the RFP Process to Open Source

I was part of a conversation on open source ILS alternatives recently and Art Rhyno talked about opening the RFP process, allowing open source solutions to become more accessible to our traditional business models. This idea really struck a chord with me, especially since the disruption and opportunity created by SirsiDynix's ditching of the Horizon product. The RFP process is one that provides a layer of objectivity and business logic around a process that is often much more subjective than we care to admit. It is also designed to prevent organizations from going with a preferred vendor when there are others (maybe more local companies) that could also provide the service/resource more cost-effectively. The problem with the process when applied to software acquisition or development is that it assumes the older model of commercial software implementation is the only game in town. With the advent of more and more cost-effective open source solutions, institutions either want to, or need to, have a process that allows open source solutions and business models to be part of the solution rather than a peripheral activity.

Open::RFP is the term I would use to describe such a process. [Note: there is a business called OpenRFP, which oddly enough services libraries, but it is a support for the traditional model.] I'm not sure what Art had in mind, since we didn't talk about it in great detail, but here are some of the characteristics I think an Open::RFP system might have.

1. A project description and functional specification that indicates the requirements using best-practice open standards, metadata formats, services, etc., rather than focusing on only the "business requirements". In my experience RFPs often mention open standards, but it tends to be marginalized in many contexts, with a real focus on the local workflow requirements.
2. A list of open source components and applications that provide a framework for delivering on the requirements listed in the RFP. The system would allow specific open source systems to be listed as either required components of any bid, or exemplars of required components. This would allow bids using commercial systems, but with an open foundation for comparison. The key idea here is that it would allow/encourage/facilitate bids from organizations proposing a service model around a set of open source components. This is very difficult to do (if not outright prevented with a statement excluding OS) with the current RFP model.
3. The ability to define a standard Open::RFP template for specific types of applications, such as an OpenURL linking system. The OpenRFP system that I mentioned above is one example of a system that does this.
4. An RFP system that provides anyone with access to the RFP documents and information on a publicly accessible website, with blog announcements of new RFPs. The goal is to move the RFP process from the closed environment they tend to operate in today to one with a greater degree of accessibility.
5. An RFP system that requires all interested parties to create an account and list their interest in being either a Lead (Institution/Company/Group/Indivudual) or a Resource (Institution/Company/Group/Indivudual), or both. Leads and Resources would list their basic information, again accessible to all, including skills, experiences. etc. Using this system of registration, individuals and companies could develop potential partnerships in response to the specific RFP. A subsequent RFP Team would be responsible for responding to the specific requirements (via the Lead), in a confidential framework, with their specific approaches, implementation process, costs, etc.

A very simplistic view on what can be a very complex process, but one that highlights some of the dysfunctionality with the current system, as well as the opportunity to build one more responsive to the open source option. This kind of system would help discover the kinds of local and distributed resource teams that are typical of open source, build local capacity, encourage the adoption of open source software and philosophies and many more. Equally important for many, it would maintain those protections that the RFP process provides to institutions looking for innovative solutions to their business requirements. I am aware of one open source RFP management system (TenderSystem), so it may be possible to build something like this with a little more thought and effort regarding a sea-change in the process itself...

The Evolution of Open Source | Linux Magazine

The Evolution of Open Source | Linux Magazine

A nice article from Linux Magazine on the changes being wrought in the open source business landscape. The article provides a nice summary of the OSLS.CA approach :-) A few quotes:

Let’s get one thing straight: open source software isn’t “on its way” into the enterprise. It isn’t creeping in, slowly but steadily; it isn’t sneaking in the back door; and it isn’t a cheap alternative to Windows. No, open source software is well-established in the enterprise, and adoption goes way beyond Linux.

Support can be particularly vexing, with companies juggling support contracts with dozens of different commercial open source companies or trying to tackle problems internally without the proper expertise, either one a risky and time-consuming proposition.

Fortunately, there’s a cost-effective solution emerging in the form of third-party, open source services companies. This new breed of open source company doesn’t sponsor any particular package; instead, it focuses on the broader challenges of open source, helping enterprises take advantage of its many benefits, while minimizing the burdens of deployment and management.

The real opportunity for growth is in demystifying the use of open source. Those third-party, open source firms that focus on helping enterprises develop policies, pick projects, and manage deployments are the ones most likely to succeed and excel.

The future of this practice is in finding a way to serve up tested, certified, and stable stacks that are easily tailored to each customer’s specifications. Much like Dell revolutionized the customization of PCs and made it the standard, I expect that the future of open source stacks is in made-to-order flexibility, not a menu with a handful of options.

What customers need is not one shop with its own experts in hundreds of different open source packages- it’s just not feasible. But they still want “one throat to choke” to feel comfortable with using a diverse group of packages. With open source, expertise is distributed far and wide, so the best way to offer that assurance is by aggregating different sources into some form of “federated support.” By developing relationships with the right developers and serving as an intermediary to secure their services, third-party open source companies can offer support for a hundred or even a thousand projects with a single contract.

Open Source ILS Opportunity Knocks

As discussed in numerous blogs recently, including my own LoomWare , recent development in the commercial ILS arena provide an incredible opportunity to reshape the software landscape for libraries. In fact, the opportunity is there for every aspect of higher education.

OSLS.CA was created to provide educational institutions with an alternative to the traditional RFP/commercial software model of software acquisition and support. OSLS.CA is a distributed network of open source programmers and specialists who are committed to the implementation, maintenance and support of open source in education. Core to the philosophy of OSLS.CA is the development of local expertise, enhanced with a network of experts and resources not possible in the traditional model. The .CA is a reflection of this, as we will focus all of our efforts on implementing solutions in the Canadian educational landscape.

The list of software components on the right is just some of the systems we will be able to provide support for. Over the next few months we hope to begin the OSLS.CA project by working with a number of organizations on various library components, including the ability to test and review the Evergreen ILS system. More information will be posted here as this initiative move forward.

If you would like to get involved in the OSLS.CA initiative, please contact Mark Leggott.

Welcome to OSLS.ca

This is the new home of OSLS.ca, an effort to build capacity around the development of open source solutions in learning, especially in higher education. More to come soon...