Guest Blog Post: Web 2.0 and Sustainability

Today’s guest blog post comes from Ross Gardler, manager of JISC’s OSS Watch service and a co-facilitator of a workshop session at IWMW 2007 on “Sustainable Services: Solidity based on Openness?”.

---

At OSS Watch we spend a considerable amount of time highlighting sustainability as one of the key benefits of open source. There is no central organisation that can simply “pull the plug” on the product and its maintenance. Open source licences ensure that the software will always be available and, while there are active users of that software, it will always be maintained.This perpetual availability of open sourced software is only one of the key benefits provided by open source licences. Another is the ability to take that software and customise it for your own needs. To add new features and to disable features not important to your situation. In other words to take a “close fit” solution and mould it into a “better fit” solution.Web services that provide open Application Programming Interfaces (APIs) present similar mix-and-match benefits, at least on the surface, that open source provides, but does it provide the same level sustainability in your solutions?This was the topic of a workshop session I hosted with Andrew Savory at the Institutional Web Management Workshop 2007 entitled “Sustainable Services: Solidity based on Openness?“. In this session we asked how participants measured the sustainability of their chosen software solutions. The list of criteria produced included items such as:

• reliability
• reputation
• scale of the provider
• significance of us as a customer
• data ownership and openness
• fashion
• community
• flexibility

The full list was far too long to detail in this post, but a few were clearly more important than others. This became particularly evident when we proceeded to evaluate a number of well known Web services against the defined criteria.

For example, data access was critical in most Web services. Was the data available in an open standard that made it interoperable with other services? Having put data into the service, could you get it out again? Flexibility was another major concern for the API approach. Did the API allow us to achieve what we want to achieve?

I would argue, like Mark Pilgrim, that this should not be an issue, we should have access to our data, and all derived data, as a matter of course – it’s our data after all. Mark observes that “praising companies for providing APIs to get your own data out is like praising auto companies for not filling your airbags with gravel.”

Workshop participants also noted that there is no guarantee that a service will be provided in the future. A topic that Brian Kelly discussed here in this blog when Splashblog closed its doors. Brian suggested that such closures could be considered by some to be a clear justification for not making use of such external Web 2.0 services – a point made by a number of our session participants. Indeed, many services were marked down quite heavily since they are largely unproven beta services with no clear business model. Despite this healthy concern over the longevity of service offerings, workshop attendees felt that some services, such as Shibboleth, are more sustainable because they have public money behind them. However, as Brian goes on to observe, even public sector services are not guaranteed to be there forever. To support his point Brian cites a BBC news article describing the closure of 551 government Web sites and wonders what happens to data held by the AHDS when funding ceases.

The overall conclusion of our workshop attendees was that Web services should only be relied upon for non-critical functions in your institution. Over time we may become more comfortable with relying on third party services, but for now we need to be careful. I liken it to the development of voice communications technologies. We don’t worry about having a dial tone the next time we pick up the phone, but the recent Skype outage shows we can’t rely on the newer voice communications services. The result is that Skype is not suitable for emergency calls.

Reaching Sustainability Through Openness

In my opinion one way of moving towards more sustainable services at a sensible pace is through openness in the development of those services. That is, if a service uses open data standards, provides fully open access to all its data and its APIs and encourages users to participate in the ongoing development of the service, I, as a user, am more likely to stick with it past my initial, experimental, use. For example, I love the idea of Dopplr, but I haven’t gone past exploration because it fails to provide the data in format that is useful to my objectives (Editor’s Note: Phil Wilson pointed out that a Doppler API has recently been announced at http://dopplr.pbwiki.com/. This comment was added at the request of Ross Gardler on 6 Septmeber 2007). Conversely, just 10 hours after the announcement of a beta API for OhLoh I had integrated OhLoh data into Simal, the OSS Watch project cataloguing tool. As soon as OhLoh produces an API for submitting data I’ll ensure the flow is two way, making both projects more likely to survive.

However, openness should not stop at the data and the APIs. I need to ensure that the service remains aligned with my strategic objectives. I want to be able to contribute directly to the flexibility and sustainability of the service in ways that suit my needs. This is where Oh Loh falls down, it is not open source and so my contribution options are limited.

Open source enables us, as users, to choose how to invest our resources in sustainable solutions. We can purchase related products such as support and hosting, or we can fund strategic development, or we can ensure our own staff help support and sustain the product through direct contribution of use cases, documentation, feature requests, bug fixes and even new feature implementations. All of these actions help ensure the product survives and continues to be available to our own organisation.

Web service companies will gladly accept similar contributions from us. The big difference between the two approaches is that with open source we have the freedom to decide where our resources are invested. We can maximise the impact our investment has on our individual utilisation of the service, thus making the service more useful. We are even free to take the software and create our own version should our objectives diverge considerably from the originating service provider (although this can usually be avoided if the project is well managed and cultivates a healthy community).

Most of us want the convenience of a service provider, but such convenience comes with the risk of potential lock-in and, even worse, the loss of a critical service. Having access to the source code means that we increase competition and consequently increase innovation in the code base. It does not prevent companies from differentiating themselves through the provision a more reliable and usable service within their chosen market niche.

Given the choice, I will always use a Web service that makes its source code available under an open source licence, even if that service is less developed than closed competitors. In most cases I will still purchase the service from a provider, but I want to keep my options open in order to ensure my own offerings are sustainable.

Our workshop participants largely agreed with this view, they too were more concerned about having control over their own organisations future in the long term than they were about the short term gains of adopting closed service models.

Ross Gardler
OSS Watch
OUCS
13 Banbury Road
University of Oxford
Oxford
OX2 6NN

OSS Watch Web site: http://www.oss-watch.ac.uk/
OSS Watch blog: http://involve.jisc.ac.uk/wpmu/oss-watch/