Archive for the 'Strategy and Policy' Category

Can open source reduce costs?

Published by Ross Gardler on March 1, 2010 in Procurement, Development and Strategy and Policy. 0 Comments

It is often said that open source software will reduce costs.

Those with little or no experience of implementing computer systems assume these savings come from the fact the free and open source software does not carry a license fee. However, this is not usually the case.

Anyone who has rolled out an software solution, even in a small organisation, will tell you that there are hidden costs. These include training, support,  customisation and maintenance.

In 2005 BECTA published “A study of the spectrum of use and related ICT infrastructure costs” which concluded that training and support costs accounted for 60% of total cost for any software solution. The report also found that open source software reduced these costs by 40-50%.

Further to reducing training and support costs, open source can reduce the cost of customisation for specific environments.

It is extremely rare for a back-office software solution to be a perfect fit for any specific organisation straight out of the box. Consequently, the software needs to be customised to suit specific needs. In a closed source environment there is a single provider, or a limited set of approved providers, who can make these modifications. However, in an open source environment anyone with the appropriate skills can make these modifications, including internal staff.

As a result of this competition, market forces can often result in a lower cost for a tailored product. Just how much can be saved here depends on the customisations you need to make.

Finally, the open source culture of code sharing results in lower development costs for the software in the first instance. That is, once one user has commissioned a specific feature or configuration option the results of that work is available to all. As a result, the more a product is used and developed within any given domain, the more widely the development costs are shared. In addition to a reduction of costs open development can significantly increase the rate of innovation as it brings together great minds to collaborate on shared solutions.

Where there is no pre-existing solution to match ones needs the open developent model can be an extremely cost effective way of reducing cost. This process is examined in more detail in our document “Meritocrats, cluebats and the open development method: an interview with Justin Erenkrantz.”

Governance Models - everything you wanted to know but where afraid to ask

Published by stevelee on February 18, 2010 in Development, Software, Strategy and Policy and Community. 0 Comments

After an extensive gestation period, OSS Watch are pleased to have jointly published 3 documents on the important subject of Governance Models for open source projects. That is excellent value for your money.

The documents on our web site undergo a rigorous quality assurance process that ensure they are technically correct and well scribed. The result in this case is an comprehensive introduction to a topic that can be over looked by projects, or may cause confusion and uncertainty.

I have on several occasions heard lead developers say that if they make their code open source they fear they will loose control and anyone can update their source, leading to chaos. As you read these documents you will see that this clearly should not be the case. The project leaders remain in control, in fact they make the decisions on who the leaders are and how the project is controlled. The governance model describes how this happens.

Having a governance model in place is one of the clear marks of an open source project that practices open development. That is, it marks a project that positively encourages community engagement.

Governance models provides an introduction to the what, why and wherefore of managing an open source project.

A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community. It is the governance model that prevents an open source project from descending into chaos. This document explains why a governance model is necessary, considers some of the challenges associated with adopting a governance model in open source projects, and looks at the key areas such a model needs to cover. It also describes how to encapsulate your governance model in a governance document.

Meritocratic governance model provides a detailed insight into this common model that is lead by an elected leadership team or ‘board’. A template is provided for use by projects interested in applying this model.

The meritocratic governance model is a commonly found model in which participants gain influence over a project through the recognition of their contributions. The Apache Software Foundation (ASF) is perhaps the most famous example of a large-scale meritocratic community. The foundation operates with an almost completely ‘flat’ structure, which means that anyone willing to contribute can engage with their projects at any level.

Benevolent dictator governance model describes another popular model where one person leads the project and has a final say in decisions. Again a template is provided for projects wanting to use this model.

A benevolent dictatorship is a project controlled by a single leader. Perhaps the most commonly cited example of the benevolent dictator model is the Linux Kernel project, which is run under the direct decision making leadership of Linus Torvalds. Being a benevolent dictator is not an easy job. It requires diplomacy and community building skills, in-depth technical knowledge of all aspects of the project, and exceptional levels of commitment and dedication. However, as the Linux Kernel project illustrates, it can be very effective.

With any project, good leadership or management are vital, and these documents will help you install the basics with little overhead. If your project already has a governance model in place then these documents could help you refine it, perhaps by making it explicit. If you don’t yet have one, then these document will help you decide what model best suits your style, and quickly get it into operation.

And you can do it all without any sign of pointy hair.

The virtuous circle model of support for open source

Published by Ross Gardler on February 10, 2010 in Development, Strategy and Policy and Community. 1 Comment

On the OpenCast Matterhorn developer list the following question was recently posted by Rudiger Rolf:

we have a release of Matterhorn now, and people start to use our system and they need support. I’m sure that many of us are willing to help these adopters, but in which way should they communicate with us?

This prompted a discussion I have seen many times, and so I was prompted to post my response here.

In my opinion there are two main reasons why someone would support a user:

  1. they are selling services
  2. they want to improve the quality of the product

Financial transactions should be divorced from community activity and thus, from a community perspective, we are left with those wanting to improve the project (I’ll return to paid support later though). People providing support in the community have two main objectives:

  1. increase the number of users
  2. understand the problems users are facing in order to improve the product, to attract more users

Increasing the number of users will ultimately increase the number of contributors (bug reports, feature requests, documentation, user support etc.) and eventually developers (code improvements). Thus attracting users is a key part of creating a successful open source project.

However, not all users will become contributors, and not all contributors will become developers. In fact, the numbers of people progressing along this scale of contribution is very small. Nevertheless, just one contributor is a reduction in the centralised cost of development and thus a step towards sustainability for the project.

For some people the idea of free support for a growing number of users appears to lack scalability. They ask “if we are attracting users at a faster rate than contributors/developers how does the project continue to provide support? Surely there is  a danger of too many resources being devoted to support and not enough on development.”

These are common concerns in a growing project. However, these assumptions ignore the fact that some people are willing to pay for support. The ideal solution is to provide a user support mailing list along with supporting documentation. There is a need to encourage everyone to assist with these community support channels. This channel should become the place where the not only users get support, but also where those providing paid for support seek support themselves. However, support provided from the project community is provided on a voluntary basis and therefore no guarantees of service are provided. The message is clear, if you want guarantees of service then you need to pay for it.

Of course “paying for it” may not mean in cash. For example, if an organisation is known to provided paid for support but they also provide resources for project management, documentation, code or some other contribution they are earning “credits” to get support themselves.

Over time, the number of “first level user support requests”grows. However, the number of people able to answer these questions is also growing, lets not forget that some of those users are still around and are now indebted to the support community. Furthermore, since a healthy project encourages people to contribute early by documenting their experience in FAQs and getting started documentation there is an increasing amount of support documentation for newcomers.

This self-help culture enables core community members to focus on bug reports and feature requests rather than first level support requests.For those users who need a fast turnaround on support requests, they will have to pay. They may contract a third party or they may use local resources to set up a local support infrastructure.

If these paid support providers are smart they will reduce their own costs by interfacing with the wider support community via the project support lists. They will both consume and produce commons support materials in the project. They will also recognise that visibility in the community support channels is a form of marketing for their paid-for services. And this is where the virtuous circle finally closes.

Mailing lists vs. forums

Published by Sander van der Waal on December 15, 2009 in Development, Discussion and Strategy and Policy. 5 Comments

On Monday the 9th of December we organised two simultaneous workshops on open development. One track was about open innovation whereas the other focused on the theme of building an engaged community around open source software projects. I gave a presentation on the latter track about my first experiences with an open source project and explained about the community tools that are essential for open development: a good homepage, a version control system, an issue tracker and mailing lists.

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.
Continue reading ‘Mailing lists vs. forums’

Guest Post: Peter Cudd on the freedoms discovered through open development

Published by stevelee on November 20, 2009 in Development, Strategy and Policy and Community. 1 Comment

This post is by Peter Cudd BSc PhD, Senior Research Associate and project lead of Maavis at the School of Health and Related Research, University of Sheffield.Our project, Managed Access to Audio, Visual and Information Services (Maavis), is also being guided in its open development journey by OSS Watch. Open development has been a new experience for me and my colleagues, OSS watch’s input has been invaluable in providing insights and giving us a concerted plan to work towards having an active open development community. Our project is at an earlier phase but there have been some real differences to the traditional closed research and development we usually do.First and foremost is being able to talk openly with anyone about the project and what we are doing – this greatly facilitates engagement with new contacts without significant increased workload. This has lead to new partnerships and joint working. For example we have successfully obtained some Knowledge Transfer funding to help create a new version of Maavis and foster the open development community. Starting from the health and social care designed Maavis the goal is to have one suitable for community based Adult Education. In addition the Barnsley Adult Education Services will evolve their own open source development capability.Another significant difference is that the impact of competing similar ideas and technology is less than would be the case for a closed approach to research and development, the open development retains more ‘nett’ validity in pursuing further research and development.Although we have yet to post a Maavis web page – next on the agenda – we are already on the open development road and feel we are making good progress.Thanks OSS Watch.