Archive for the 'Discussion' Category

Software Sustainability

Published by Ross Gardler on June 30, 2009 in Development, Discussion and Community. 0 Comments

The EPSRC recently issued a call titled “Software Sustainability“. This topic is something that is close to the heart of OSS Watch, so naturally OSS Watch submitted a bid (and, in fact, were named as partners on a number of other bids).

Collaboration is the key

OSS Watch have been acutely aware for some time that the “standard” approach to software sustainability in our sector is to “throw more money at it”. Indeed, most of the bids into this call, that we are aware of, take this approach. At OSS Watch we take a longer term view. We believe that sustainability is about reducing long term cost through collaborative development, this requires a short-medium term investment in developing collobarative software development skills. Unfortunately, our sector is more accustomed to competition for grants than to collaboration for value for money.

Evidence of this can be seen in the OSS Watch experience during the writing the our EPSRC bids. We were approached by a number of people who refused to allow us to talk to others about their plans, a ludicrous situation since some of the gaps in experience in one proposal could be closed by bringing in another member of our network. In other cases we invited representatives of potentially competing bids to view and discuss our own bid in order to find points of collaboration. Some joined our open mailing list  and viewed our draft proposal in the wiki but not once did they contribute, they didn’t even acknowledge our invite. In other words they wanted to take, but not to give.

The end result of this competition is, in this case, a number of less than ideal bids. This prompted OSS Watch to sumbit a bid that explicitly called for the EPSRC to match our own bid with another with, in the funders eyes, a suitable domain specific expertise. Assuming that our bid is seen as valuable in itself we look forward to sharing our expertise with one or more of the other bid teams.

How do we collaborate?

It is our belief that to create sustainable software that survives between one development team (i.e. grant) and the next (i.e. another grant) we need to change this culture of competition into one of collaboration. In the non-academic sectors there are significant examples of this working on both large and small scales.

The problem with this approach is that project team currently expect their own chances of survival to be dependant on their “ownership” of the outputs and knowledge acquired during the first grant. Indeed OSS Watch are an example of this. As OSS Watch manager I am responsible for ensuring we have enough grant funding for over five full time staff. If I encourage others to enter our space am I putting my team at risk?

I don’t beleive so, my team have a very specific set of experiences and skills. Collectively we cover most aspects of open source software development. Our network reaches far and wide into the academic and non-acadmic open source communities, but we are not omnipresent. By being clear about our specialisms and recognising other groups expertise we should be able to increase the amount of grant money we recieve as we will get access to more varied pots through our cooperation. What the sector needs to realise and accept is that by being the expert one will be invited to participate in more projects not compete for less.

Whilst OSS Watch’s experience in this EPSRC bid would seem to simultaneously support and undermine this argument, it is our belief that in the long run cooperation is where value and sustainbility lies. There  are examples of this happening with niche software produced in the acadmic sector too. For example TexGen, a project at University of Nottingham has recieved significant additional funding as a direct result of the openness of their software outputs.

Sucessful collaboration means fully open collaboration

Unfortunately, TexGen is the exception rather than the rule. Even where collaboration is the goal, our sector still tends to artificially limit membership of the community to those who are funded. This can be seen in the Community Source model, popular in large US projects which excludes some parties from participation and therefore limits the sharing of both costs and rewards to a smaller group than is necessary.

The community source model aims to add a level of control to open development projects that it is believed does not exist in true open source. However, I would argue that this is a lack of understanding of the open development model rather than fact.

My own experience shows me that there are decision making models in open development that allow for the level of central planning and control needed in major projects whilst still ensuring the doors are open to anyone who wishes to contribute in a sensible and construcitve way. Indeed, if this were not the case then open source, and sustainable, products such as Eclipse, which is found at the heart of a large number of varied third party tools, would not exist.

In order to demonstrate this to be the case OSS Watch have been working with some experienced community source practioners in the Matterhorn Project. Together we have drawn up a governance model for this new project which appears to satisfy the control concerns of the funders whilst also satsifying OSS Watch’s concerns about keeping the commuity open.

At first glance this model may seem somewhat heavyweight for a smaller project. Therefore, OSS Watch have also worked with other parties to develop a much lighter touch governance model suitable for “rapid innovation” projects that are funded for just six months.

Those of you who read these models will realise that they are essentially the same model, it’s just that one defines more formal roles than the other since it has more initial stakeholders. This means that should the rapid innovation project be succesful it’s model can grow to accomodate a growing, and as yet unknown, community. It is this growth that is the start of sustainability through a collaborative development model.

The practice of open development

Now that OSS Watch have started to show that closed communities are not required, the next step is to encourage people to develop their software in such a way as to ensure non-community members are empowered to participate. It is these third party contributions that spread the cost of development across multuple financial pots and thus reduces centralised risk.

We recognise that policy is all very well but it is practice that matters. The adoption of open development practice requires a significant cultural change, but this is a change that our research shows is desired byenough practitioners to make it viable.

OSS Watch argues that funding projects to experiement with software ideas and then spending more money to “harden” the few that have promise is wasteful. We believe all software should be developed openly from the outset. By doing this the cost of sustaining software that succesfuly meets user needs is decreased since initial outputs, of all kinds, are reusable. Where software does not meet user need, as can often be the case in research software development,  the increased level of collaboration and awarenees within the community serves to increase the chances of success in future projects. This is because the community is sharing not only the “hardened” successes, but also the lessons learnt in other projects.

Procuring Software is not (even) as simple as buying a car

Published by Ross Gardler on April 15, 2009 in Procurement, Business and Discussion. 3 Comments

Here at OSS Watch we often get asked things like “which is the best open source twitter alternative” or “which is the best open source financial managment tool?” We don’t answer these questions, and for good reason. Instead we focus on helping people understand how to find and evaluate open source software solutions. In this blog I’m going to try and explain why we take this approach.

With simple things like microblogging we can point to Laconica with a resonable amount of comfort, but should we really be ignoring Open Micro Blogger simply because we have not used it ourselves, after all, it does focus on a stronger and more scalable back-end. What about the solutions we’ve not yet heard of? A quick search for “open source microblogging” turns up a fair number of projects that are worth a look, not to mention a promising looking article with the title “Top 10 open source microblogging services. Perhaps it’s not as simple as we first thought.

If it is this hard to identify “best of breed” open source solutions for something as simple as a microblogging service how hard would it be for a “Financial Management and Reporting” system? These are complex systems that need to be customised (or at least configured) for each use case.

Sometimes the enquirer pushes a little harder, often indicating that it should be possible to identify “best of breed” and that OSS Watch should do so. However, our position remains firm, we can’t evaluate everything out there, but we can help people identify and evalate the options in the context of their needs.

Lets consider the financial software market. I’ve used Compiere for Financial Management in the past. I was very pleased with it, but it’s not really a financial system, it is a Enterprise Resource Planning and Customer Relationship Management system that has some financial functionality.Would the CRM and ERP functionality help or hinder our requestor?

As well as Compiere I’ve used a pen and paper based double entry ledger system. It worked, requires minimal technical knowledge and is easy to source. Unfortunately it is error prone, requires considerable training and usually needs a real accountant to do magic periodically, magic you don’t want to be paying accountant hourly rates for when software can do it, perhaps GnuCash or jGnash would be a better option. However, these are targetted at personal finance not business (or academic) finance.

Then there are OpenER, SQL Ledger, TurboCash and all the others that are out there. These are all “best of breed” within their own domain. They all have strengths and weaknesses. The “best” depends entirely on whether their strengths are important to the user whilst their weaknesses remain hidden.

How did I come up with the (incomplete) list of financial tools above? Simple, I spent 7 minutes (yes I timed myself) searching the web and making snap decisions on the viability of the open source community built around the products. I rejected another four or five as they looked like unsustainable or immature projects. It is this skill that I think we can offer to people looking for open source solutions. The customer must then narrow down the choice by looking at the feature set of the product base. Once a short list is drawn up, OSS Watch can help evaluate the support options available for the project, that is we can help the customer decide if the open source solution fits their culture, e.g. is there a suitable commercial support offering or is there an active and supportive developer community that internal IT staff can engage with?.

Even when we explain this in some detail we find that some people still insist that we should be able to tell them what to buy. So, I’ll say, here and now, as loud and clearly as I can:

Procuring something without actually considering the functionality it will need is insane. It is almost certainly doomed to fail.

A software procurement specialist once told me “there is never enough time to do it right, but there is always enough time to do it twice”. I wish I’d listened to him then (I’ll not go into why, but involves lots of wasted money). At least I’m listening now. If you are ready to listen, you can stop reading and contact OSS Watch when you want us to help you evaluate some open source solutions.

For those still unconvinced let me try and illustrate the problem in a domain most of us know a little about.

Imagine you are buying a new car. All cars have the the same basic functionality and features, they go forwards and backwards, they have a steering wheel and they stop before hitting things (assuming the driver is alert enough to hit the brakes).

Despite all cars being the same (when considering base functionality) we don’t walk into a the local car dealership and say “what’s the best car” and immmediately buy the first thing that comes into their mind. Instead we find out which are the most suitable cars for our kind of use (driving to the shops, commuting, long distance travel, fun at the weekend etc.). We probably also read literature and reviews. Most of us would test drive a couple of our favourites. Eventually we would buy one.

It’s true that we rely on reviews and salespeople to help us narrow down the choice, but we have other methods for making the final selection, and, importantly, we would usually ask salespeople from each of the major manufacturers.

Anyone who watches car “review” programmes like Top Gear knows that even in the simple world of cars there is never a clear winner between two cars built for the same purpose. One will be better cruising on the motorway, the other may be better on country lanes. One will be cheaper to run, but the other mighter be cooler to look at, but beauty is in the eye of the beholder. It is not usually possible to say “this car is better than that car, regardless ofwho you are and what you are looking for”.

Sometimes it is possible to say “this car is just rubbish, it broke down 5 times in our road tests”, but once you get past obvious flaws that affect everyone you have to understand the drivers needs before saying “this car is the perfect car for you”. I’m 6′ 4″tall, I simply don’t fit comfortably into some cars, it doesn’t matter if everyone else in the world thinks it is the perfect car, for me it is rubbish.

[This is getting to be a long post so I won’t even start on considering maintanence options for the car once it is purchased.]

Since most people wouldn’t ask a really general question such as “what is the best car?”, why do people insist on asking OSS Watch things like “which is the best open source financial management software solution?”

OSS Watch can help you procure open source solutions, but we can’t tell you what to buy - sorry, it just is not that simple.

A good API is not enough

Published by Ross Gardler on March 16, 2009 in Development and Discussion. 0 Comments

[The post below was written for the JISC “Good API’s” project, but I like to get as much mileage out of my work as possible so I’m posting it here too]

We often argue about whether we can trust service X or whether we can hold our data in service Y. This usually boils down to whether the provider of the service is likely to survive, whether the data is secure and whether we can access it in an open format via a documented API. We usually fail to consider the influence we will have on the providers of the service or software exposed by the API, we therefore fail to consider our own futures.

For this post I’ll limit myself to thinking about web based APIs (which we should not do, but since the UK HE and FE communities tend to think API means access to a web service I’ll do the same here). In this sitution we need to consider access to the source code that implements the API. This should be an important part of our decision making process for many reasons , the most important of which is that it increases the options available.

As an example we can consider microblogging, an area that is getting a fair amount of attention in the education sector, see Brian Kelly’s WebFocus Blog for examples.

Twitter, probably the most popular of microblogging platforms, is web based and provides a clearly documented and reasonably complete API. Institutions and researchers are currently considering solutions based on microblogging systems like Twitter. The focus of such efforts include questions like “will Twitter be here in 5 years?”, “what is their profit model?”, “will they start charging soon?”. These are important questions because the instituion will have no control over their own systems if they depend on an external service like Twitter.

For small organisations with no IT support, the use of Twitter is attractive. It is low cost, feature rich and popular. Should the model of use within Twitter change a small organisation can adapt quickly. However, for larger organisations like Universities and Colleges something like Twitter can embed itself, almost unseen, into many different systems across the organisation. For example, it could be integrated into institution wide news networks, the student VLE and and researchers VRE, the student tracking systems and the lecturer feedback mechanisms (to name just a few of the ideas I’ve heard). Clearly an institution can quickly become dependent on a microblogging service and thus the longevity of Twitters support, at current pricing levels, is very important to medium and long term planning.  Unfortunately, there is no way of knowing where Twitter is currently heading and so planning becomes very difficult.

Some commentators argue that depending on any third party solution is too risky and inflexible. Others argue that third party solutions can provide significant cost savings with only a limited sacrific of flexibility. What we really want is a middle ground. A solution in which we can take advantage of third party solutions for as long as the opportunity cost of doing so falls below the cost of developing our own, independent, solutions. Fortunately, there is such a “third way”, that third way is open source software.

Continuing our example of a microblogging service,  an alternative to Twitter is identi.ca. Like Twitter, Identi.ca provides an API for accessing the system and so it can be integrated with in-house systems. It provides all of the features of Twitter and content can be bridged between the two (via the respective APIs). There is, at least on the surface, no significant difference between the two systems.

However, the Identi.ca platform is built using Laconica an open source microblogging tool. This means that if the hosted identi.ca service becomes unsuitable for any reason one can “simply” install Laconica on a suitable server and continue as before. Of course, it really isn’t that simple, by moving away from the Identi.ca server you are taking on the responsibility of maintaining your own server. You may also be forcing your users to rebuild thier social networks on yet another system, which presents a barrier to use. Fortunately, there is a middle ground in this case too. Since Laconica is open source, any third party could set up a company providing Identi.ca like services, including, for example, a group of collaborating universities.

It is tempting to say that an API is good if it provides the functionality we need and the ability to export our data if we decide to move on. However, as we have seen, this is not always enough, not when we need to plan strategically. Web based APIs are, in some cases, merely a way to provide the flexibility to customise systems whilst still locking you into a single provider solution. Experience has shown us that a monopoly in any domain is a dangerous thing.

We must be able to avoid lock-in to any individual providers services. Simply being able to export data from our current service provider is not sufficient. We also need to be able to find an alternative provider. Whilst open source does not guarantee the existence of an alternative it certainly increases the chances of one being created where demand exists. This in turn puts additional pressure on other providers to satisfy the needs of their existing customer base. This pressure often manifests itself through the provision of a more complete and flexible API. This can be seen in the example of the Identi.ca API which not only implements the full Twitter API but goes much further.

UK Government to level the playing field?

Published by Ross Gardler on February 25, 2009 in Discussion, Strategy and Policy and Standards. 5 Comments

In May 2008 OSS Watch published a workshop report with the title “Levelling the playing field: developing a mixed economy for software procurement”. This report focussed on procurement in the Higher and Further Education sectors and recomended that we work to:

  • ensure all solutions use open standards and provide protection against vendor lock-in
  • facilitate better communication with senior managers across HE/FE as to the potential benefits and pitfalls of making use of open source solutions
  • encourage educational ICT bodies with an overview of the sector such as UCISA and BECTA to assist institutions with open source related training and knowledge
  • work to improve the ITT and PPQ processes within institutions

OSS Watch has been funded by the JISC since 2003, part of our remit has been to facilitate the appropriate adoption of open source in the sector, yet the recomendations made in our workshop were largely the same as they were in 2003. Did this mean that OSS Watch was having no effect?

I’m pleased to say that OSS Watch have had some influence on the adoption of open source in the  education sector. For example, we worked with our own funders on an open source policy which was adopted in 2004. Similarly, we worked with BECTA during the creation of the Open Source Schools project (as well as helping BECTA understand what the goals of this project were we continue to provide advice, guidance and materials to the company running the site).

However, when it comes to influencing individual procurement decisions we have struggled to have any significant impact. Put bluntly, there is very little our small team can do when faced with procurement policies and staff that are predisposed towards the incumbent suppliers products.

I was therefore encouraged when the Cabinet Office published “Open Source, Open Standards and Re–Use: Government Action Plan“. This document is intended to put open source software onto an equal footing with proprietary forms for procurement.

As with the 2004 government policy on open source we are assured that “Procurement decisions will be made on the basis on [sic] the best value for money solution to the business requirement, taking account of total lifetime cost of ownership of the solution, including exit and transition costs, after ensuring that solutions fulfil minimum and essential capability, security, scalability, transferability, support and manageability requirements” and “The Government will use open standards in its procurement specifications and require solutions to comply with open standards. The Government will support the development of open standards and specifications.”

However, this new document goes a small, but important, step further.

It states “Where there is no significant overall cost difference between open and non-open source products, open source will be selected on the basis of its additional inherent flexibility.” Many commentators have, so far, missed the importance of this statement. The key is in the acknowldgement of “additional inherent flexibility”. This is over and above the flexibility provided by the adoption of open standards.

This “additional inherent flexibility” is a result of having access to the source code. Closed source software can adopt open standards, but they still provide a form of lock-in since there is only one source of customisation and maintenance for that product. When the source is freely available one is able to shop around various support providers in addition to selecting from various interoperating products.

The introduction of competition through open standards is clearly a step in the right direction. However, competition between software providers is also desirable. This is a topic I cover when presenting at procurement related events, and is something OSS Watch believe is very important given that requirements for software usually change as an organisation matures. These changes may not be aligned with the business model of the current support provider.

I’m also encouraged to see that the document identifies a number of actions including “develop clear and open guidance for ensuring that open source and proprietary products are considered equally” (action 1). This is a very complex issue and is something OSS Watch have been trying to do in the education sector for some time.

The problem is that open source and closed source solutions cannot be compared using the same techniques. Whilst the software products themselves can be compared on a feature by feature basis, the softer aspects, such as quality of support, security, flexibility and sustainability of the solution cannot be easily compared like for like. Consequently, it is necessary to change the procurement process itself before any real impact will be seen. Simon Phipps of Sun Microsystems suggests one potential model for a level procurement playing field through adoption led approaches, and warns about how the existing process can be gamed.

Further to the need to change the procurement process we must also ensure our workforce has the necessary skills to evaluate and engage with open source software. Without this skillset policies and action plans will fall on deaf ears, who is going to implement them? I discuss this in my November post “We have an open source future - or do we?“

Despite these concerns, I welcome this document from the Cabinet Office and encourage those with an understanding of open source and, in particular, how it should be evaluated to actively review and comment on the document using the CIO defined tag of #ukgovOSS so that it gets picked up and syndicated on a special public FOSS Aggregation page.

Building FOSS and Education links

Published by Ross Gardler on February 2, 2009 in Development, Discussion and Community. 0 Comments

At OSS Watch we often find that it is hard to find software developers who really understand what open source is about. All too often people think it is simply a way of licensing software.

It is true that the licence is extremely important, critical even. But it is also true that on its own, an open source licence is not sufficient to create good software (surprise!). For good open source software we also need to understand how to manage and engage with users and (if we are lucky) the developer community. This requires a set of skills not commonly taught as part of a typical computer science or software engineering degree. Yet learning to manage a succesful open source project is not difficult.

Recently OSS Watch have been working on some plans to start solving this problem. More accurately, we have been looking at ways to bring together the excellent work of others and tie it into formal education and work based learning. These plans are still solidifying, but they are progressing well and we now have a very impressive line up of collaborators, ranging from little old OSS Watch all the way up to some of the heavyweights of the open source software world.

Many of these  people, and some others, will be meeting at a pre-FOSSDEM EduCamp. Anyone interested in these issues should consider signing up for the event which is likely to be both useful and fun.