Category Archives: Strategy and Policy

Kuali governance change may herald end of ‘Community Source’ model

For quite some time now at OSS Watch we’ve struggled with the model of “Community Source” promoted by some projects within the Higher Education sector. Originating with Sakai, and then continuing with Kuali, the term always seemed confusing, given that it simply meant a consortium-governed project that released code under an open-source license.

As a governance model, a consortium differs from both a meritocracy (as practised by the Apache Software Foundation) or a benevolent dictatorship, or a single-company driven model. It prioritises agreement amongst managers rather than developers, for example.

We produced several resources (Community Source vs. Open Source and The Community Source Development Model) to try to disambiguate both the term and the practices that go along with it, although these were never particularly popular, especially with some of the people involved in the projects themselves. If anything I believe we erred on the side of being too generous.

However, all this is about to become, well, academic. Sakai merged with JaSig to form the Apereo Foundation, which is taking a more meritocratic route, and the most high-profile project using the Community Source model – the education ERP project Kuali – has announced a move to a company-based governance model instead.

I think my colleague Wilbert Kraan summed up Community Source quite nicely in a tweet:

‘Community source’ probably reassured nervous suits when OSS was new to HE, but may not have had much purpose since

Michael Feldstein also provides a more in-depth analysis in his post Community Source Is Dead.

There’s good coverage elsewhere of the Kuali decision, so I won’t reiterate it here:

A few months ago we had a conversation with Jisc about its prospect to alumnus challenge, where the topic of Kuali came up. Back then we were concerned that its governance model made it difficult to assess the degree of influence that UK institutions or Jisc might exercise without making a significant financial contribution (rather than, as in a meritocracy, making a commitment to use and develop the software).

Its hard to say right now whether the move to a for-profit will make things easier or more difficult – as Michael points out in his post,

Shifting the main stakeholders in the project from consortium partners to company investors and board members does not require a change in … mindset

We’ll have to see how the changes pan out in Kuali. But for now we can at least stop talking about Community Source. I never liked the term anyway.

Thoughts on TYPO3

Last month, OSS Watch delivered a series of sessions on communication and participation with open source communities at the TYPO3 Developer Days event in Eindoven.

One of the sessions in our series looked at the theory of communities, the varieties of the communities we form and the motivations involved in each.  The core message of the session is that a FOSS community should be a community of interest, with the interest being the problem solved by the community’s outputs.  While many people in a FOSS community are developers, it’s wrong to view it as a community of practice, since other skills are required for a sustainable community.

What’s unusual about the TYPO3 community, is that while it is presented to the world as a single group, the brand actually encompasses 2 distinct groups. One group produces the TYPO3 CMS system, while the other produces the TYPO3 Flow framework and the TYPO3 Neos CMS.

The original development of Flow/Neos was funded by the TYPO3 Association as the “next generation” of the TYPO3 CMS. Indeed, it was originally called TYPO3 v5.  However, after the initial development of v5, TYPO3 v4 usage and development continued.  When it became clear that v4 wasn’t going away v5 became TYPO3 Neos, and the next version based on the v4 codebase became TYPO3 CMS v6.

The situation now stands that the TYPO3 brand is used by 2 distinct projects which have different development teams, different stated values and different cultures.  While the TYPO3.org website makes the history of the project and the branding guidelines clear, I feel that the TYPO3 community as a whole still has an issue to address.

The Sakai community (now part of the Apereo foundation) experienced a similar situation not long ago.  A sub-group of the Sakai 2 community decided it was time to produce a next-generation system, and called it Sakai 3.  However, it soon became clear that many  institutions funding Sakai didn’t agree with the goals of the Sakai 3 project, which created a rift in the community.

Several key partners withdrew their funding for Sakai 3 (which was rebranded Sakai Open Academic Environment, now called Apereo OAE) and continued to use and develop Sakai 2 (rebranded Sakai Collaboration and Learning Environment, now just Sakai).  The 2 projects now co-exist within the Apereo Foundation, a foundation created to foster software projects which support the goals of higher education.  While the projects have survived, the community suffered.

When a community moves from being a single-project to a multi-project community, as both Sakai/Apereo and TYPO3 have, it’s important that the resulting community identify what key commonality make them a single group.  A FOSS community should be a community of interest, and if projects are to share a community, they should have a shared interest.

Apereo has identified its shared interest in software that supports higher education, within which Sakai and Apereo OAE can now co-exist. With this identity, they’ve now taken on additional projects such as Matterhorn and uPortal, with an incubation programme foster new projects in the future.

If the TYPO3 community doesn’t identify the shared interest of TYPO3 CMS and Neos/Flow, they risk suffering further turbulences as Sakai’s community experienced several years ago.

Fortunately, the TYPO3 community are not blind to these issues. Members of the TYPO3 projects have formed a Community Working Group to look into the issues discussed here and steer the community towards a positive future.

It’s my hope that by learning from Apereo and similar multi-project communities, TYPO3 could become a successful umbrella organisation in its own right.

For more on the history of Sakai and the Apereo OAE, check out the “Sakai” tag in Michael Feldstien’s blog archives from 2010 onwards.

Open source in education: where does the change need to happen?

In our recent survey on free and open source software in the UK education sectors, we asked colleges and universities for their main reasons for not selecting an open source solution according to 12 criteria. Below you can see how important each of the criteria were rated for software running on servers:

Interoperability and migration problems 80
Lack of support 71
Poor quality software 60
Not what users want 51
Lack of staff expertise, training needs 49
There is no open source solution for our needs 43
Legal issues including licensing 30
Time costs of identifying relevant software 29
Migration costs 25
Existing contractual obligations 18
Poor documentation 15
Solution does not scale 14

The question I’d like to pose today is – if we were to consider these as representing the barriers to greater adoption of free and open source software in education, are the barriers to be found within institutions, or are there issues with the available supply of software and services to the sectors?

To answer this I’ve split the criteria into two groups – supply-side and demand-side. Lets look at the supply-side first of all.

Supply Side Factors

Supply-side factors

Three of the top four criteria are supply-side considerations: lack of support, poor quality software, and not offering what users want.

We could also consider “There is no open source solution for our needs” as being largely the same thing as not offering what users want, which would place it as the top concern.

This would imply that, from the perspective of colleges and universities, the open source software community just isn’t offering the kind of software products the sectors need.

From our experience in compiling the Open Source Options for Education list, this would seem a bit curious. Perhaps the issue is one of awareness and marketing? Or are there significant niches in education where there really are no open source options? We also know that the procurement processes in many institutions would likely exclude open source from consideration – is this also a factor in this lack of awareness?

The second major issue on the supply side would then be the provision of services and support. As we’ve seen in the public sector, having commercial partners is a crucial factor in getting solutions adopted. (There is a chicken-and-egg issue here is that there has to be adoption to support a services market, but lack of services hampers adoption.)

Finally there is the quality issue – are open source solutions aimed at education really poor quality? Or is it that the kinds of solutions being considered are not mature?

Now lets look at the demand side.

Demand Side Factors

Demand side factors

The top issue is interoperability and migration problems – if we also add in the respondents who considered migration costs, then it is by far the most cited reason why open source isn’t selected.

We’ve noted before that there is no simple relationship between open source, open standards, and interoperability; while in principle open source affords the adoption of open standards and greater interoperability, the practice is a lot less clear cut.

However, what we haven’t untangled here is whether the issue is with open source options lacking interoperability features or standards compliance, or whether the issue lies with the incumbent systems they would replace.

The next ranked issue is lack of staff expertise; again we haven’t untangled whether this is a lack of expertise amongst the potential users of the software, the IT operations staff, or the staff involved in the procurement so its hard to interpret precisely. Given the question relates to server software it could be any of these groups.

It may also be the case that this issue goes hand-in-glove with that of lack of support from the supply side; often for server-side software the complexity of configuration and operations can be overcome by contracting a supplier to deal with it on your behalf. For  open source options, if there are no suppliers of services available then its up to the institution’s staff to figure it out.

Finally, the rest of the issues here fall under the category of contractual, legal and procedural issues with procurement itself. While each individual item is not ranked highly, taken together they suggest there are significant barriers still in place in procurement. This is something we’ve been looking into recently in more depth, for example in our Decision Factors for Procurement briefing.

Conclusions?

Taken altogether, the demand side and supply side issues of open source adoption in education carry pretty much equal weight from the viewpoint of the institutions themselves. But what are we to make of it?

I think we can distill it into five challenges:

1. We need to tackle the interoperability question. Is lock-in a problem? Is lack of standards a problem? This is something our friends at CETIS could take a lead on.

2. We need to improve awareness of existing open source solutions available within the sector;  lists like our Open Source Options for Education are useful here, but projects also need to be more proactive in raising awareness, and may need a higher profile at events such as the UCISA and ALT conferences.

3. Institutions need to improve software procurement processes so that they can consider open source solutions effectively and equally with closed source.

4. We need to build up the open source services market for education. ULCC have been very effective with their Moodle hosting, but companies supporting other major open source software solutions don’t seem to have much of a presence in the education sector. (As I mentioned earlier though, this is a bit of a chicken-and-egg problem)

5. Bootstrap projects in areas where there are no existing open source solutions. Of course there are well known problems with funded projects, but there are alternative approaches, for example the Jisc Co-Design programme could play a role here.

Open source policies in UK universities and colleges – what’s changed over the past 10 years?

As a result of the OSS Watch National Software Survey, we now have 10 years of survey data on open source in universities and colleges in the UK, so we can look at some long term trends. Today I’ve been looking at institutional IT policies.

Back in 2003, most IT policies in colleges and universities in the UK didn’t mention open source at all, while today that position is reversed.

We’ve also seen the demise of policies that prohibit open source; while at the same time policies that state a preference for open source also seem to be on the way out.

policies

So, are universities and colleges moving towards a “level playing field” approach to open source and setting “equal consideration” policies? Perhaps; though IT policies are only a part of that equation.

We also have survey data from 2008-2013 for what types of software are being considered for procurement and deployment in practice:

effects

So, equal consideration of open source software is on the increase, but there is still a long way to go; and if the rate of change over the past five years is anything to go by, we’ll never get there!

Perhaps what we’re seeing is a lag between changes in policy filtering through into changes to processes and practices – or perhaps its not filtering through at all.

For more information on open source policies and procurement processes, read our briefing note Decision factors for open source software procurement.

The full results of the 2013 OSS Watch National Software Survey will be published in January

Is Open Source Insecure?

tl;dr: Open Source is inherently no more or less secure than closed source software.

banksy stencil with security camera

For a more thorough answer to this question, we’ve just updated our briefing note, “Is Open Source Software Insecure? An Introduction To The Issues” where we look at some of the ways in which software is considered secure, and look at some of the common claims both for and against the security of Free & Open Source Software.

On the whole there are no significant differences in security between closed and open source software as a category. The key differences are between individual products, and the governance processes around security – something which applies to both closed and open source software.

Claims that Open Source is inherently insecure – or, conversely, that it is inherently more secure – are unfounded and should be challenged, particularly in the process of selecting and procuring software. Accepting such a generalisation may actually be increasing security risks for the organisation, by excluding the most fit-for-purpose solutions from consideration.

Photo by nolifebeforecoffee of a stencil by banksy.

Running open source virtual machines… on Microsoft Windows Azure? Welcome to the VM Depot

Last week I gave a talk on open source as part of a Microsoft Azure for Education day at UCL in London. I was sharing the stage with Stephen Lamb from Microsoft, who gave a great overview of the various open source projects that Microsoft are engaged in, including Node.js and PHP for Windows. But the main highlight was VM Depot.

cloud

VM Depot is a way to upload, share, and deploy virtual machine images on Microsoft’s Windows Azure cloud platform. For example, you can easily find common open source packages such as Drupal and WordPress on various Linux operating systems available as VMs, so that you can create and run your own instances.

This makes it very easy to get started with open source packages, as all the dependencies and related components and configuration are all set up and ready to use – for many packages this means just doing your customisation for things like your own web domain and personalising the user interface.

As well as the usual suspects such as Drupal, the VM Depot can host all kinds of other software; for example, you can deploy the Open Data portal platform CKAN. This opens up possibilities for using the service for more niche requirements, for example you could create a VM image of your research software and dataset to make it easier for reviewers to run your experiments. Or you can modify an existing image to include extensions and enhancements that may target a more specialist audience, for example you could create a WordPress image with templates and add-ons to run as an overlay journal rather than a regular blog.

So why is Microsoft doing this?

Well, it seems to fit as part of the drive towards Microsoft being less of a software company and more of a device manufacturer and cloud services provider. When it comes to offering  cloud services, its less important what your customers choose to run on them, so much as making sure they can run whatever they need. For most organisations that usually means a mixture of closed source and open source packages; by offering the VM Depot, Microsoft can serve these customers as part of an existing relationship, rather than force them to go with other service providers for running open source products.

Microsoft have certainly come a long way since the infamous “cancer” remark.

For more on Microsoft and Open Source, check out Microsoft Open Technologies.

Open Source and Open Standards key to future of public sector IT

Last week Open Source, Open Standards 2013 took place in London, an event focussed on the public sector. Naturally these being two topics we’re very keen on here at OSS Watch I went along too.

Overall the key message to take away from the event was just how central to public sector IT strategy these two themes have become, and also how policy is being rapidly turned into practice, everywhere from the NHS to local government.

Tariq Rashid, the Open Source policy lead for the UK Government, spoke of the need for IT to be focussed on user needs, and to deliver sustained value, by moving from “special” software procured for the public sector, to services delivered using commodified IT.

Even where services are unique to the public sector, Rashid and other speakers at the event made the case that most elements of such services can be delivered by building on commodified IT. For example, the open source CMS Drupal is used for delivering increasing numbers of public sector IT services, and the Government Digital Service builds its services from open source components.

The two strategies of Open Source and Open Standards are necessary as they create the ‘competitive tension’ needed to drive down cost and improve sustainability.

Mark Bohannon of Red Hat gave an overview of the global landscape of Open Source in government, in the US and UK, and identified the UK policies as being particularly forward looking. Mark positioned Cloud and Big Data as two key areas where Open Source and Open Standards were critical, calling out OpenStack and Hadoop as particular cases, and also provided some great case studies on open source from the military and from space exploration.

Mark made the point that Open Source and Open Standards underpin a more fundamental change in IT, away from big IT projects towards IT that is agile, modular and responsive to user needs.

Ian Levy of CESG dispelled some myths around security and Open Source (“If anyone in UK government says CESG has banned open source send their name to me and I’ll have them killed”) and made the case for a common sense approach to security, whether the software or service is open source or closed source.

Mark Taylor from Sirius has long been an advocate for open source in the public sector, and it was good to be at a point where the message has been heeded! He began with a nice Schopenhauer quote:

All truth passes through three stages. First, it is ridiculed. Second, it is violently opposed. Third, it is accepted as being self-evident.

In the talk he provided lots of practical advice for public sector organisations on putting Open Source into practice, which include calling on those writing tenders to focus on user needs instead of naming technology solutions. Mark also gave a workshop later in the day where he continued this theme, expanding on how public sector organisations and companies had made transitions to open source. Its not very easy to summarise here in a post, but I found the information very practical and useful; for example, when transitioning IT, to start with the systems furthest away from users, such as backend services and infrastructure, to avoid sparking the usual neophobia when you change technologies for users.

Inderjit Singh gave an overview of the NHS standards-based approach to IT, with some nice background on which approaches had been tried and where the current strategy is going. The current approach has been to use a programme of change projects involving SMEs that have engaged 40 new suppliers, and which is accelerating the take up of the standards.

Singh asserted that standards and fundamental for enabling an open architecture, and that open source and open standards go hand in hand in delivering value for users.

After some workshop sessions, we had Alasdair Mangham from the London borough of Camden giving us a look into how they’ve been building services using open source software in collaboration with SMEs. This involved a major shift in contracting – rather than write an huge set of requirements in a tender document, they disaggregated the project and bought in specialist capabilities (in usability, service design, SOA etc) as needed in smaller chunks of time using an agile process.

Graham Mellin gave an overview of the Met Office’s new space weather system built using open standards and using open source software; for their own specialist systems they decided to go down the route of making it Open Source rather than the private partner sharing route as result of an exploitation planning process.

I met with a lot of people at the event, from suppliers, local government, NHS and national government departments, and it was good to get a sense of how the public sector is moving – whatever the pace in individual areas – towards this vision of more affordable, sustainable and user focussed IT, and better utilising the capabilities of UK SMEs and startups.

We pointed out recently in our post in the Guardian, Higher Education in particular is in a strong position in this area as a result of past investments in Open Source and Open Standards, and we now need to think about how we take that forwards.

As Mark Taylor pointed out in his talk, the public sector accounts for over half of IT spend in the UK – and we can choose to either unite and use that market power to shape the future, or be divided up and conquered.

Open Source meets Open Standards

OSS Watch Briefing Paper: Open Standards and Open Source

Open source software and open standards are two of the key interventions in technology policy, whether that policy is made by governments, public sector organisations, or companies.

Open standards can ensure interoperability and assist portability, allowing the switching of solutions and avoiding vendor lock-in. Standards can also help to create new markets, and can also encourage innovation within markets by imposing useful constraints.

Open source software offers benefits of greater flexibility and the potential for reduced development costs and better software quality through collaboration and reuse.

Together, open source and open standards provide the basis for solutions that offer interoperability, cost reduction, and flexibility; no wonder they are seen as such a powerful tool for technology policy!

However, whats often less clear is how the two interact in practice. There is, for example, a fairly widely-held view that open source software is somehow inherently more likely to support open standards. However, in practice this is not necessarily the case, and there are a number of barriers that can actually make it less likely for open source projects to implement standards than their closed-source counterparts.

Open source and open standards should complement one another - but can also counteract each others benefits if policies are developed without paying attention to the way they interact

For example, implementation of a standard requires access to documentation; in many cases this involves payment for access, or paid membership of a consortium – something that open source projects may have difficulty with unless a benefactor or sponsor does this  on their behalf. Also, if a project wishes to publicly claim that it implements a standard, this may involve a formal conformance process requiring paying fees for testing and accreditation.

So for policy makers and CIOs, the selection of standards, and the standards setting organisations they originate from, can have a significant impact on the availability of open source solutions to meet their requirements.

Mandating standards that involve patent licensing fees, mandatory expensive conformance testing and assurance, and restricted access to documentation will exclude many potential solutions and providers. This will have the impact of increasing costs, and potentially eliminating the benefits of standardisation altogether if organisations have little practical prospect of switching suppliers.

Conversely, if standards are selected that provide a low barrier to entry to open source then this can be good not just for individual solution procurement, but for interoperability as a whole.Unlike closed-source solutions, with open source it is possible to inspect the implementation of standards and to conduct independent interoperability and conformance testing rather than rely principally on vendor claims. The presence of open source implementations can also influence uptake of a standard; either by making open source libraries available for use within other products, or by providing a good target for interoperability testing for other entrants.

Open source and open standards are key components in technology policy; but its important to know how they can work together – and potentially work against each other.

A new OSS Watch briefing paper provides an overview of the main issues facing implementation of standards for open source projects and developers; for more information see Open Standards and Open Source.