. 

On Sunday at 17:17 (GMT) March 7th my wife gave birth to a beautiful and healthy baby girl, Saskia Frances Gardler at 7lb 10.5 oz. Mum and baby are doing very well and are now home with a proud Dad.

I’d like to publicly acknowledge the superb  care that my wife and I received during this pregnancy. We only truly appreciate the National Health Service when we really need it, and Heidi and I have  needed it on far too many occasions over the last few years. The care we have received has been exceptional when compared to what I have seen in other countries.

I should also mention Oxford University Computing Services. I could not have hoped for a more understanding employer, it was clear from the first day that as long as I worked hard when I was able OUCS would respond by giving me as much space and time as I needed to support my family during this difficult period. I’m truly grateful to my boss Lou Burnard and to my exceptional team here at OSS Watch.

As for extended family and our friends - we hope they already understand how appreciative we are of their combined efforts in recent years.

Like I said in the intro, sometimes life is horrible, but more often than not life and the people around us are wonderful. We should never forget that in the difficult times.

The Sahana Software Foundation are looking for additional developers to help with Sahana, a disaster management tool. They need to continue to build an information portal that is seeing increased interest and usage to assist organisations responding to events in Haiti. Information on the work underway can be found on the Sahana Haiti response Overview page.

The skills they are primarily looking for are (you don’t need them all, any will do):

•  Python - the main development for SahanaPy is Python (we’re not using PHP for this instance)
•  web2py - Sahana uses the web2py enterprise framework for SahanaPy (I’m told it is fairly easy to learn if you’re used to Django)
•  OpenLayers
•  jQuery

To find out more and offer your help please jump onto #sahana on freenode. Please give as much or as little as you want.Some of the core devs have been working really long hours the past 5-6 days, and any additional resource would assist us greatly, particularly as the effort is really starting to get some interest, traction and coverage, which leads to more and more feature requests.

Thanks for reading this far - please consider giving a few hours of your time to help out, if you can.

This has been a very hard piece to write. We felt we needed to talk to as many people as possible, we needed to sift through  significant amounts of Fear Uncertainty and Doubt along with unnecessarily emotional responses.

Things weren’t made any easier by the fact that every time we felt ready to publish something else heppened that seemed to change the story somewhat and we had to return to our sources for more observations.

During our research for this article OSS Watch have been accused, by an OSI board observer and ASF Member, of being “surrogates” for Microsoft, whilst Tony Hey (Corporate Vice President of External Research, Microsoft) privately expressed concern that OSS Watch was “encouraging academics to use the GPL.” Simultaneously, various free software representatives have pointed out how “naive” they believed us to be by even considering the idea that Microsoft may have genuine intentions with respect to engaging with the free and open source community.

As a non-advocacy advisory service we tend to think that if all sides in a debate believe we are in the wrong, yet all are still talking to us, we are probably doing something right. Certainly none of them can claim us as their own.

Given all this input what did we conclude?

Well, as you would expect, the conclusion is far from clear. On the one side we have the Stallman’s (Free Software Foundation) view that “these free programs are meant specifically to prevent the world from freeing itself from non-free software”. On the other side we have Erenkrantz’s (The Apache Software Foundation) view that “every positive and constructive engagement Microsoft has with the open source community (and vice versa) … will continue to chip away at the old perceptions”.

Furthermore, whilst Microsoft may be making concessions to open source and are happy to play with open source when it suits their needs they are also willing to use other methods where it best suits their business. For example, on patents Darren Strange (Head of Open Source Engagement, Microsoft UK) says “Patents drive innovation and they drive openness actually.”

Our own conclusion is that “Microsoft is not simply an unchanging monolith.” The article demonstrates that things within Microsoft are changing. Naturally they are changing in ways that benefit Microsoft as a business, but the good news is that some of these changes also benefit the world of free and open source software.

Over the years I have often quoted Ghandi when looking at Microsoft and their relationship with Free and Open Source Software: “First they ignore you, then they ridicule you, then they fight you, then you win”. FOSS has not “won” yet, but the frontline is moving and it is open source software that is winning.

One question at the end of my session was about the mailing lists. I had explained that it is very important to have a publicly accessible mailing list that anybody can subscribe to and that you should ensure that all communication about the project is on the mailing list. The question was about why you should use mailing lists for this and not forums.
(more…)

I have never written a blog before, and seldom read them, so I had a few questions for my colleagues. What shall I write about? Oh, anything really. Who am I writing for? Oh, anyone and everyone. Scary. All the more so because blogging is  personal and immediate - quite the opposite of the book publishing process I am used to, where the product is carefully crafted over several weeks or months and there’s a team to share the responsibility.

Luckily I went on a course yesterday, so at least I have something to write about. The course was called Writing for the Web, and I was keen to go on it because I wanted to know how the writing and editing processes for the Web differ from those in book publishing.

The course outline looked very promising: devising a strategy for your website; understanding how people read online; structuring your information; writing skills; managing your website; editing and proofreading; and creating reusable material. For me, it didn’t quite deliver on all fronts, but I did pick up some useful tips:

• a website should not be seen as whole, and is non-linear, unlike most books
• reading on screen is uncomfortable, so presentation is important (see http://webpagesthatsuck.com for examples of how not to do it)
• consider the reader’s environment and accessibility issues
• use storyboarding to plan the site, and to demonstrate layout of screens and navigation links
• navigation reflects the relationship between information and also readers’ need to access it
• people don’t read the text, they scan it, so make it scannable: use highlighted keywords, meaningful sub-headings and bulleted lists
• keep headings short; the first two words are the most important
• paragraphs should contain a maximum of two sentences
• keep it short and simple (see http://www.plainenglish.co.uk/) and focus on the action
• avoid ’speed bumps’: inconsistent use of terms, jargon, slang, non-descriptive headings, marketing hype

All in all, it was a useful day away from the office. I will now be able to look at our website in a new light, and think about how we could apply some of these principles to improve it, and the documents we write for it, for our readers. Pity we didn’t cover blogging.

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 collaborative 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-academic 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 receive 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 sustainability lies. There  are examples of this happening with niche software produced in the academic 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 constructive 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 satisfying OSS Watch’s concerns about keeping the community 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 accommodate 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 multiple 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 by enough practitioners to make it viable.

OSS Watch argues that funding projects to experiment 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 successfully 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 awareness 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.

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.

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.