OSS Watch team blog

One of the hot topics of commentary on open source development at the moment is the licensing situation on GitHub.  When code is committed to GitHub, the copyright owner (usually the author or their employer) retains all rights to the code, and anyone wishing to re-use the code (by downloading it, or by “forking” and modifying it) is bound by the terms of the license the code is published under.  The point of discussion in this case, is that many (indeed, the majority) of repositories on GitHub contain no license file at all.

There are two troubling points to the commentary on this phenomenon.  The first is that some discussions suggest that publishing with no license is “highly permissive”, implicitly allowing anyone to take the code and do with it as they wish.

In fact, it’s usually the case that having no license on your code is equivalent to having an “All Rights Reserved” notice, preventing any re-use of your code at all.  Whether it’s the copyright holder’s intention to enforce these rights isn’t being made clear, but it’ll be enough to put off any company who might want to engage with such a project under an open development model.

The second troubling point is that commentators are time and again dressing this up as a wilful movement.  James Governor coined the term “Post Open Source Software“, while Matt Asay claims “Open Source Is Old School, Says The GitHub Generation“.  These commentaries seem to imply that there’s some sort of “No License Manifesto” being championed (in a similar fashion to the Agile Manifesto, perhaps).

The only movement I’ve seen which would be akin to this is the Unlicense, which encourages authors to wilfully lay aside any claims to their rights, effectively a Public Domain dedication which Glyn Moody has suggested is the way forward for open source.

However, what we’ve seen on GitHub shows no such conscious setting aside of rights, it shows a lack of education.  Publishing articles touting release without a license as how all the cool new kids are working encourages behaviour which could prove damaging to the development of a project’s community, and the wider community in turn.

Fortunately there are voices of reason in these discussions.  Stephen Walli of the Outercurve Foundation points out that governance == community.  If a project seeks to “fuck the license and governance” as James Governor suggests, then they risk doing the same to their community by alienating contributors (particularly those that are part of a larger organisation, rather than individual developers), as these contributors have no predictable structure to work within.

If the project lead might turn around and say “I dont feel like accepting your contributions, and by the way, if you keep using my code I’ll sue you”, you’ve got very little incentive to work with them.

By neglecting your community in this way, you project is at risk of being limited to a few individual contributors who know and trust one another implicitly.  I can’t believe that developers seeking to allow permissive use of their code would be happy with this as an outcome.

GitHub haven’t yet made any suggestion that they feel this is a problem they should work to solve.  It’s our responsibility as a community to ensure that we educate newcomers to become responsible open source citizens, rather than encouraging them to follow established bad practices.

Licensing and governance analysis form 2 cornerstones of OSS Watch’s openness rating.  If you’d like advice on how to improve your projects management of these areas, please get in touch.

At OSS Watch we periodically review all the resources on our main website to make sure they’re accurate and up to date. Last week it was time to revise our case study on Apache Wookie, which is a project I’ve been involved with for some time.

OSS Watch became involved with Wookie while I was working in an EU project based at the University of Bolton. The project as a whole had done lots of interesting stuff, but as with many large projects the whole was somewhat less than the sum of its parts; the central joined-up platform wasn’t really going to take off after the project finished. However, in the process we had built quite a promising system for adding functionality to the core portal shell using the W3C Widgets specification.

Towards the end of the project I went to an OSS Watch event, and spoke with Ross Gardler about what we were doing. Ross explained the Apache Incubator model to me, and from there on I was hooked.

Fast forward to 2013, and Apache Wookie is out of the incubator and a top-level Apache project, and is now on its seventh official release (the last one was in April). Its not a huge project – the team is still small, though its far more diverse than when we started out.

The tempo of development has also slowed in recent years. However, in part thats due to the maturing of the software to a point where code churn for its own sake has a negative impact on the projects that depend on it. Most recent updates have been fixing bugs affecting deployment in various unusual configurations, driven largely from reports by users. So this isn’t necessarily a bad thing!

Something that has also had a very positive impact on the project is having a very active downstream project – Apache Rave. This has driven a lot of improvements to Wookie to improve integration and deployment.

Two major EU projects have been working with Wookie and Rave over the past two years, and are coming towards their end – one this year, and the other in 2014.

Unlike previous projects they have focussed on working with existing software projects rather than going it alone, and have contributed code, user studies and content.  This has been a great experience, and hopefully future projects can learn from this approach.

Wookie stands as an example of how OSS Watch can help take work from within the HE sector and turn it into a sustainable open source software project; and as a beneficiary of this approach I’m keen to offer the same help I received to others.

Do you think your University-based project has the potential to go further? If so, get in touch!

Read the updated case study on Apache Wookie at OSS Watch.

(Photo by Silus Grok, used under CC-BY-SA license)

As part of OSS Watch’s regular review of our website’s content, I’ve taken a look through the publicly editable version of our Open Source Options for Education list and added some new contributions to our website.

The response from the educational community has been overwhelming in helping us find both alternatives to common proprietary software and real-world examples of these alternatives being used.  I’d like to extend my thanks to everyone who’s contributed.

I’m particularly pleased this time to include a new category for Management Information System (MIS) software.  These tools often represent a significant investment to an institution and requirements for compatibility with these systems which perform a key administrative role can be a strong influence over procurement of related software such as VLEs.

You can find the updated version of the Open Source Options for Education document on the OSS Watch website, and continue to contribute to the public version on Google Docs.

Almost any software project involves working with dependencies – from single-purpose libraries to complete frameworks. When you’re working on a project it’s tempting to bring in libraries, focus on meeting the user need, and figure out the niceties later. However, a little thought early on can go a long way.

This is because every dependency can bring its own licensing obligations that affect how you are able to distribute your own software. In some cases, in order to release the software under a particular license you may end up having to rewrite substantial amounts of software to remove reliance on a library or framework that is distributed under an incompatible license.

So there is a tradeoff between being agile and productive in the short term, against the risk of needing to do a costly refactoring triggered by a compatibility check before – or even worse, after – a release.

For larger projects, and organisations with multiple projects, this starts to stray into the territory of open source policies and compliance processes, but for this post lets just focus on the basics for small projects.

A good strategy is to build good dependency management practices into your general software development practices – similar to the concept of building in quality or building in security.

In other words, given that the cost of fixing things later can be significant, it’s worth investing in the practices and tools that can ensure potential issues are spotted and fixed earlier.

At its simplest, this can just mean developing a greater awareness as an individual developer of where your code comes from,  knowing that what you reuse can limit your choices for how you license and distribute your own code.

So in practical terms, this means being careful about copying and pasting code from the web, and making sure you know the licenses of any dependencies, preferably before working with them, but certainly before building any reliance on them into your code.

It may also make sense to handle any required attribution notices for inclusion in a NOTICE and README as you go along, rather than just rely on a release audit to always pick them up.

There are also tools that can help make things easier. For example, if you use Maven for Java projects, there is a License Validator plugin that can help flag up problems as part of your compile and build process.

Alternatively, Ninka is an Open Source tool for scanning files for licenses and copyrights. While it can’t follow import declarations or dynamically linked libraries, it can be useful to periodically check builds. A similar project is Apache RAT (Release Audit Tool) which was originally created for use within the Apache Software Foundation for reviewing releases made in the Apache Incubator.

For larger projects and organisations there are also complete open source policy compliance solutions like Protek from Black Duck, or Discovery from OpenLogic.

It’s also worth pointing out that, while tools can be a part of the solution – and can be invaluable for large projects – ultimately it’s still your responsibility to make sure you meet the obligations of the software you are reusing.

If a dependency has a compatible licence, thats great. But what about if the project that distributes it doesn’t bother checking their own dependencies?

This is where it’s good to have an idea about the governance and processes of projects you depend on.

There aren’t just licensing risks associated with dependencies – if you rely heavily on a library that has only one or two developers then you also run the risk that it may become a “zombie” project with implications for the rest of your code, for example, if security patches are no longer being applied.

Beware of zombie projects!

The commercial tools mentioned above are also typically backed by a knowledge base that can also flag up other issues with dependencies, such as governance or sustainability problems.  However, just having a check for the project on Ohloh is often good enough for most smaller projects to check that a library is still “live”.

If you need to know more about the sustainability of a particular project, OSS Watch can carry out an Openness Review to check its viability using a range of factors – get in touch with us if you want to know more.

Some organisations make use of component registries to keep track of which components they approve on in their software projects. This can save time spent by developers researching the same libraries, but makes most sense when you have a lot of projects that probably need the same kinds of components, in which case focussing on reusing the same set of libraries makes sense.

Another reason for using a registry is where you need to perform more detailed evaluations, for example for security, and so checking a dependency is more involved than just figuring out which license it uses, and that the project isn’t dead.

Some examples of commercial registries are Sonatype Component Lifecycle Management   and Black Duck Code Center. Again, for a smaller project or an organisation with a relatively small set of projects this can be overkill, and just having a shared document somewhere where you can keep note of which libraries you’ve used can be effective.

For example, you could share a spreadsheet with colleagues containing some basic information on each library like what version you’re using, what license it’s under and the date and results of any investigations you’ve done into sustainability, security or risk assessment.

Reusing code is good practice and should save you time and expense – so it’s annoying if the administration associated with it starts affecting your productivity.

You can make a judgement call about what level of risk you feel is acceptable; for example, on an internal-only research project the risk of having to undergo a major refactoring should the project be successful may be one worth taking.

However, for a production system, or a component that is itself intended for reuse, you may just have to accept that you have to be a bit more diligent in how you reuse code.

Photo by DieselDemon used under CC-BY-2.0.

The Guardian Careers site published an article yesterday discussing which skills you should have on your CV to ensure your application is “at the top of the pile” when applying for IT jobs.

Among the usual traits such as being able to program (they suggest Java, but with a willingness to learn new languages), one of the recommendations is “Open up to open source”.

In a succinct paragraph the article manages to introduce the idea of open source, as well has explaining both its benefits to the public (in terms of having access to zero-cost versions of software) and why IT companies and departments would be looking for it.

Engaging with an open source community provides you with the opportunity to gain practical experience in working on projects with a distributed team from diverse backgrounds.  Any skills relevant to the IT industry would be desirable to an open source project – not just programming but also skills like project management and technical writing.

The public nature of open source projects also means that your work will be open for potential employers to examine.  Code you’ve written for a previous job may be locked up in a company’s version control system, but by contributing open source code you give a potential employer the opportunity to see evidence of your competence in the field.

Of course, beyond the benefits of the general IT skills you can acquire, specific experience in open source engagement can be of value to IT companies who are increasingly taking advantage of open source software.  To get the full value from open source implemented in an organisation, that organisation should be prepared to engage with the community process, allowing them to get bugs fixed, contribute to the project, and possibly influence the project’s direction in their favour.  To make this possible, they’ll need people with experience of community engagement.

On April 19th the United States Patent and Trademark Office finally rejected an application for the trademark ‘Open Source Hardware’. The grounds for the rejection were that the term was ‘merely descriptive’. Trademarks are intended to identify a specific source of goods or services, protecting that source from confusion in the minds of consumers with other sources. Naturally then, if you try to obtain a trademark which is just a description of a type of product or service, it is proper that you should be refused; it would not be distinctive and it would distort the market by allowing one source to control the generic term. If I market a car for a hamster, I should not be able to get a trademark for the name ‘hamster car’, as that would improperly restrain competitors from bringing their own hamster cars to market. So should we be pleased that the application was rejected? After all there is no trademark ‘open source software’ (although the Open Source Initiative do hold one for their own name and logo which acts as a kind of accreditation mark for their approved licences and projects that use them). In this case it’s a little confusing, because the applicants do not seem to have been actually looking to use the mark to describe what is usually understood by the phrase ‘open source hardware’ at all. In fact they were looking to protect their offering comprising:

Computer services, namely, providing an interactive web site featuring technology that allows users to consolidate and manage social networks, accounts, and connections to existing and emerging application programming interfaces (APIs)

Reading the decision it seems that the services relate to providing and managing services for children on a variety of devices, and that the trademark is supposed to imply the ‘general freedom’ of open source software but applied to one’s hardware devices in a surprising new way:

In support of registration, applicant maintains in Section 1 of its brief that the mark is not merely descriptive because OPEN SOURCE was used initially with the Open Source Software Movement; that applicant’s use of “open source” would associate that term with the provision of software and that “this causes a jarring effect that is overcome by the user’s imagination to the play on words.”… Additionally, applicant argues that joining HARDWARE next to OPEN SOURCE causes consumers to think of “physical artifacts of technology designed and offered in the same manner as free and open source software,” citing to the wikipedia.com definition of “open source hardware.”

So, I would argue, this is really not an application to use the term ‘open source hardware’ on what is normally understood to be open source hardware, so it’s not merely descriptive. This is more like the the Irish company that holds the trademark ‘open source’ for use on dairy products. Indeed, the decision does have a strong dissenting opinion which argues that the trademark ought to be allowed as non-descriptive but then properly obstructed by complaints from the actual ‘open source hardware’ community before its final grant.

What this shows, I think, is a couple of things. Firstly, that bodies like the USPTO have trouble understanding phrases like ‘open source’ where they relate to technology. Secondly, that terms that the community relies on to describe their interests and enthusiasms are not necessarily immune from proprietary seizure. While the decision here seems to contain an error that worked to deny the trademark, it’s possible to imagine a similar error that would allow a troublesome trademark to be granted.

In connection with trademarks and FOSS I was interested to see the establishment of modeltrademarkguidelines.org, a wiki-based site which

 …proposes language one might use for trademark guidelines for FLOSS software projects.

It already contains a very useful page listing pre-existent FOSS project trademark policies. I would encourage readers to read the draft version of the guidelines and comment.

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.

Last week BBC’s Horizon put out a special episode looking at the next generation of technological advances. Two of the stories they reported caught my eye as they suggest that the future of innovation lies in an open way of working.

Liz Bonnin presented the show from one of The Science Museum's storage hangers. Photo Credit:BBC

The first story looked at the work of Professor Bob Langer at MIT.  Professor Langer has received the Draper Prize and National Medal of Science for his work in biomedical engineering.  Langer’s approach to research is to bring experts from a range of fields together to create an interdisciplinary team.

Previous approaches to designing medical devices were designed by doctors based on existing materials.  Langer sought to design new materials to operate inside the body and be safely absorbed once their job was done.  To make this possible he assembled a team including engineers, chemists, neurosurgeons, pharmacologists and a number of other disciplines.

The approach of applying one expert’s knowledge to the problem posed in another’s primary field has many parallels with open innovation, and led to advances never thought possible by those working in single fields.

The second story reported on the Protei project which we heard about recently at Open Source Junction.  Protei was founded by Cesar Harada, and seeks to produce sailing drones which can be used to clean up oil spills.

Harada released his initial designs online and set out forming a community of scientists and engineers to collaborate on the project. Supported by a kickstarter campaign, over $33,000 dollars were raised allowing him to hire a work shop and invite his community to work together on the open hardware project.

The programme then focused on the contrast between the model of inventors patenting an invention which Harada characterised as “good for the manufacturer but not very good for the people”, to the “new culture of openness” shaping what we invent.

One comment that piqued my interest came from Gia Milinovich, who spoke of a “tension between the open source movement and business”, and a “battle between these two worlds”.  While this paints an exciting picture for a science documentary, I think the language used here was slightly disingenuous.

While we hear of stories where one company attacks another company who backs an open source project, these bear little distinction from companies litigating against each other over issues with no relation to open source. It’s fortunately very rare that we see a “battle” between a business and an open source community, and the examples of this are greatly outstripped by the examples where the two work together in harmony, indeed furthering one another’s goals.

Designer Wayne Hemingway then described how he “loved the idea” of an environment with no patents and no copyright, which while certainly a valid goal doesn’t do well to represent the way open source works.  The most common open source licences all at least require that the the original author be credited for their work, which in a copyright-free world wouldn’t be enforceable.

These criticisms aside, It’s great to see open source and open hardware getting airtime from a mainstream broadcaster like this.

While compiling OSS Watch’s list of Open Source Options for Education, I discovered Koha, an open source Integrated Library System (ILS). I discovered, with some confusion, that there seemed to be several ILS systems called Koha. Investigation into the reason for this uncovered a story which provides valuable lessons for open source project ownership, including branding, trademarks, and conflict resolution.

Read the full article at opensource.com.

In a previous post I discussed two different models for open source services; the “secret source” model, which is based on providing a differentiated offering on top of an open source stack, and a copyleft model using licenses that address the “ASP loophole” such as AGPL.

Another way of looking at these two models is in terms of the level and characteristics of differentiation that they afford.

If a service offering – and this applied whether its a SaaS solution or infrastructure virtualization or anything in between – uses a copyleft license such as AGPL, then this tends to encourage shallow differentiation. By this I mean that the service offered to users by different providers is differentiated in a way that does not involve significant changes to the core codebase. For example, service providers may differentiate on price points, service packages, location, and reputation, while offering the same solution.

There can also be differentiation at the technology level including custom configurations, styling and so on, or added features; however under an AGPL-style license these are also typically distributed under AGPL, so if service providers do want to extend and enhance the codebase, this is contributed back to the community. If a provider really did want to provide deep differentiation, it would effectively have to create a fork.

If a service offering instead builds on top of an open source stack using a permissive license such as the Apache license, then it becomes possible for providers to offer deep differentiation in the services they provide; they are at liberty to make significant changes to the software without contributing this back to the community developing the core codebase. This is because, under the terms of most open source licenses, providing an online service using software is not considered “distribution” of the software.

For service providers this presents something of a quandary. On the one hand, a common software base represents a significant cost saving as development effort is pooled, reducing waste. On the other, there is a clear business case for greater differentiation to compete as the market becomes more crowded.

How this is resolved is something of a philosophical question.

It may be that, acting out of self-interest, service providers will over time balance out the issues of differentiation and pooled development regardless of any kind of licensing constraint; the cost savings and reduced risk offered by pooling development effort for the core codebase will be clear and significant, and providers will apply deep differentiation only where there is very clear benefit in doing so, while contributing back to the core codebase for everything else.

Alternatively, service providers may rush to differentiate deeply from the outset, leaving the core codebase starved of resources while each provider focusses on their own enhancements. In this scenario, copyleft licensing would be needed to sustain a critical mass of contributions to the core.

Given that OpenStack and Apache CloudStack, two of the main cloud infrastructure-as-a-service projects, are both licensed under the Apache license, we can observe over the coming year or two which seems to be the likely scenario. Under the first model, we should see the developer community and contributions for these projects continue to grow, irrespective of how deeply providers differentiate services based on the software.

Under the second scenario, we should see something rather different, in that the viability of the project should suffer even as the number of providers building services on them grows.

As of now, both projects seem to be growing in terms of contributors; here’s OpenStack (source: Ohloh):

… and here is CloudStack (source: Ohloh):

(Both projects have slightly lower numbers of commits, though that can simply reflect greater maturity of codebases rather than reduced viability, which is why I’ve focussed on the number of contributors)

If the concerns over “deep differentiation” turn out to be justified, then community engagement in these two projects should suffer as effort is diverted into differentiated offerings built on them, rather than channelled into contributions back to the core projects.

Deep and shallow differentiation is a concept borrowed from marketing, and is sometimes used to refer to how easy it is for a competitor to copy a service offering. One example of this is the Domino’s Pizza “hot in 30 minutes or its free” service promise – it would be difficult for a competitor to copy this offering without actually changing the nature of its operation to match – it can’t just copy the tagline without risking giving away free pizza and going out of business.

In cloud services, its arguable how much differentiation will be in terms of software functionalities and capabilities, and how much on the operational and marketing aspects of the services: things like pricing, reliability, support, speed, ease of use, ease of payment and so on.

If the key to success in cloud is in amongst the latter, then it really doesn’t matter that most providers use basically the same software, and providers will want to take advantage of having a common, high quality software platform with pooled development costs.

A further problem with deep differentiation in the software stack is that this could impact portability and interoperability – having extra features is great, but cloud customers also value the ability to choose providers and to switch when they need to. Providers focussing on a few popular open source cloud offerings are another kind of standardisation, complementing interoperability standards such as OVF, and one that gives customers confidence that they aren’t being locked in; as well as being able to move to another provider, they also get the option to in-source the solution if they so wish.

It remains to be seen whether there really is a problem with the open cloud, and whether copyleft is an answer. Personally I’m not convinced there is.

However, that doesn’t mean copyleft on services isn’t important; on the contrary I think that licenses such as AGPL offer organisations a useful option when looking to make their services open.

Recent examples such as EdX highlight that AGPL is a viable alternative for licensing software that runs services, and that perhaps with greater awareness among service providers we may see more usage of it in future. For example, for the public sector it may offer an appropriate approach for making government shared services open source.

(Sea and cloud photo by Michiel Jelijs licensed under CC-BY 2.0)

Universities are ahead of the curve in adopting open source, says Scott Wilson – we should now lead the public sector in exploring its full potential.

Read the full article at Guardian Higher Education Network.

Earlier this month EdX, the nonprofit organisation set up by MIT and Harvard to provide a MOOC platform, released part of its code under an open source licence – the Affero GPL.

MOOCs – “Massive Online Open Courses” – have been hitting the headlines frequently in 2013, with high profile proponents and some big name backers. (For a good overview of the subject, I’d recommend reading MOOCs and Open Education: Implications for Higher Education, a white paper published by CETIS.)

The meaning of “Open” in MOOCs has been variously argued; however the prevailing model is one of open access to higher education, but not necessarily provided using an open platform.

The earliest MOOCs, and those operated by individuals or collectives rather than companies, have tended to operate using combinations of free of charge – though not necessarily open – services such as those offered by Google, WordPress, and Twitter, coordinated using open source course management platforms such as Moodle.

However, most of the high-profile commercially-oriented MOOCs have operated a bespoke online service based on either proprietary software, or solutions built using open source software but not necessarily available for others to replicate due to the so-called privacy loophole; that is, the modifications made to the software to deliver the service are not themselves required to be distributed to users.

The EdX announcement is interesting for two reasons – firstly that they are the first high profile MOOC provider to release open source – and secondly that they are doing so under the AGPL, one of a small number of open source licenses that specifically address the “privacy loophole”. This means that if you create your own MOOC service using EdX’s XBlock software, you must make the source code for the service – include your modifications – available to download under the AGPL. This is a form of “service provider copyleft” that ensures that EdX will have access to any improvements on their platform used by third parties.

This can be seen as a very cautious move – using the AGPL will ensure no other services can improve on the codebase without EdX getting access. However its also quite a bold one as it makes a clear distinction between how EdX sees “open” in contrast with Coursera, Udacity and others. (It remains to be seen what direction the UK’s FutureLearn initiative will take). It will also be interesting to see if other components of EdX will be released, and if so whether they will also use AGPL.

For more information on how online services use open source licenses, see How Can Services Be Open Source? 

The EdX XBlock code is available on Github.

At Open Source Junction 4 we invited attendees to present their hardware projects.  Some were open source hardware, while some used consumer hardware components in conjunction with open source software to provide an innovative solution to a problem.

Richard Hughes is the creator of ColorHug, an open source colorimeter.  These devices measure the colour coming from your screen and create a colour profile allowing you to ensure that colours look the same across all devices.  This means that a photo taken and viewed on your DSLR camera will look the same when being touched up on your laptop, and when being shown to friends on your TV.

One of the initial concerns to Richard was infringing patents of competing devices.  To avoid this, he kept his device as simple as possible – the less technically novel the device, the less chance someone else had patented a method it used.  The simplicity of the device and components could be made up for using more complex software.

Once he had a working prototype, he Richard set up a website to announce the device and start taking orders.  He hoped that he would sell a dozen or so.  Before long he had several hundred orders.

Financing production at this scale proved difficult.  Richard attempted to get a bank loan, but because his device was open source, the bank felt it was too much of a risk.  He decided to fund the first 50 units himself, using the profit to fund the next batch of 100, and so on.

As production scaled up, Richard found new ways of creating efficiencies.

Holes in the case were initially made using a Dremel multitool and a template. However, before long the hole in the template became enlarged and had to be replaced.  This process was replaced with a punch tool, which was faster and more durable.

The ColorHug circuit boards were initially printed in China and hand-soldered by Richard, who has past experience with surface-mount soldering.  However, the cheap boards had a high defect rate, and resulted in a lot of wastage.

As the production process evolved, Richard moved the circuit board manufacture to the UK, and paid for them to be tested at production.  This created a higher unit cost but dramatically reduced wastage, creating savings overall.

After soldering 50 units himself, Richard sought out an alternative.  He looked for companies to provide a pick-and-place process for the surface mount components.  Initially looking to Eastern Europe, he found companies were only willing to deal with orders far in excess of what he needed.  Again, the answer was found closer to home, with a UK factory willing to satisfy smaller orders in exchange for an initial set-up fee.

If you’re interested in the ColorHug, you can buy one (or download the designs, firmware and build your own) from http://hughski.com

Paolo Di Prodi of Robomotic introduced us to the panStamp, small Arduino-compatible boards that communicate wirelessly over an RF protocol called Simple Wireless Abstract Protocol (SWAP). PanStamps can be connected to various sensors and consume very little power, allowing them to operate on a single AA battery.

A network of panStamps can be used to measure all aspects of an environment such as temperature, air quality, noise levels, light levels, and report readings back to a base system.

A panStamp network is managed using Lagarto, a python-based device management interface for SWAP.  From here, sensor readings can be read, recorded, published, and used to trigger events.  A reading from one panStamp can even be used to activate another panStamp in the network.

The panStamp site features technical details and source code for the system.  Paolo admitted that he was initially sceptical about the open source model, but concluded that if your device is copied, it’s because you’re doing something right.

Kevin Safford is a technical writer for IBM by day.  When his mother was diagnosed with altzheimer’s, she was keen to maintain her independence. With Kevin living some distance from her, he wanted to provide her with a system that allowed her to live independently where possible, while providing him with peace of mind.

Kevin designed an unobtrusive computer system for his mum which could be administered remotely.  The hardware he chose was a DreamPlug connected to a USB touch-screen.  The software from the operating system to the applications is entirely open source.

When Kevin wants to speak to his mother, he uses VNC to log into her computer remotely.  From here he can initiate a video call to himself, allowing it to ring until she is ready, when he answers at his end.  Being able to see one another gives both parties reassurance.

Between calls, Kevin uses the computer to provide his mother with reminders and stimuli.  Using cron jobs and structured text files, he can display a daily list of events to ensure his mother knows what she’s doing, and what she needs to remember.  He can also schedule the system to play her music or show her photos, which provide a source of entertainment and stimulus.

Details of Kevin’s system including the scripts he uses can be found on his Google Code site.

Richard Melville works for Cellularity Ltd who produce the Stellar Computer System, a system of modular desktop computers which can operate independently, or be clustered together to provide a distributed and robust platform.

The Stellar system is built entirely from consumer components.  The form factor is small enough to be mounted on the back of a computer monitor.  The components are passively cooled and the storage is solid state, creating a low-power, silent device.

The power requirements are low enough for the machine to run from a 12V battery.  This can be connected to a mains charger to provide a long life UPS-style set-up, or even to a small wind turbine.

The device is designed to be modular – if the operating system fails, the device it is stored on can be swapped out for another, leaving the user data (stored separately) intact.  The case is tool-less, allowing most components to be replaced by hand.

Cellularity Ltd. is currently working with Basho to implement the Riak distributed database on a cluster of Stellar machines.  This setup would allow user data to be distributed across the cluster, meaning a machine could fail completely and be replaced with no loss of data.

You can find our more about the Stellar Computing System on their WordPress site.

Adam Cooper has been spending his spare time building hardware cellular automata.  If you’ve ever seen Conway’s Game of Life and similar simulations you’ll be familiar with the concepts – an array of cells activate, stay active and deactivate in response to those around them, based on a pre-defined rule set.

Adam’s project takes this idea into the real world.  His idea was to design a low-cost device (about £6 for a board an the required components) which would allow year 9-age school pupils to build physical automata.  With a yeargroup building a set of devices, a large array of cells could be created.

The project is currently at the prototyping stage, with the first 5 boards built and functioning.  The boards feature LEDs which allow them to signal an active state, and light sensors to detect the state of surrounding cells.

Adam’s plan is to get sponsorship for the boards to be built at his daughter’s school, and that the project will help promote interest in STEM subjects.

Once again OSS Watch would like to thank everyone who presented at Open Source Junction 4.

This post contains photos by Wolfgang Lonien, Andi Sidwell and Flickr user jabstarr

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.

At Open Source Junction 4 I took the opportunity to hold a discussion on open source hardware (OSH) communities, the barriers to community engagement, and whether UK academia needs a service like OSS Watch to support OSH projects.  This post is a summary of those discussions.

When producing an OSH artefact, there’s going to be some physical work involved.  Depending on the kind of device being produced, there may be specialist tools and processes required.

While the internals of many electronic devices can be assembled with little more than a soldering kit and a readily available box of tools, other projects may require plastic moulding equipment, 3D printers, lathes, laser cutters, or any number of specialist machines.  To enthusiasts without these tools readily available, this creates a barrier to engagement with the project.

Hackspaces offer one solution to this, as they can provide a place for specialist equipment to be shared between members.  However, tools must be looked after and maintained for this to be a viable solution – access to a broken 3D printer is of little use.

To ensure that availability of tools doesn’t become a barrier, a project should try and keep the need for specialist processes to a minimum in the manufacture of their product.  Where such a process is required, a project could find someone to perform the process and supply the resulting component to potential contributors, removing the requirement for everyone to have access to the tools.

Again due to the physical nature of OSH artefacts, the geographic diversity of a community can be another barrier to engagement.  A group may have a hard time collaborating on a device if they aren’t in the same place to interact with it.

While OSS avoids some of this issue with the ability to copy and distribute code over the Internet, there’s still an advantage to real-time contact with other community members.

Video conferencing through a medium such as Skype or Google+ Hangouts can help provide the real-time interaction and allow discussions over a physical object.  OSH communities can take advantage of these tools to share their work with each other, even if they can’t meet in person.

Local interest groups also play a part in solving the problem of geography.  As we’ve seen with Linux User Groups providing a place for local OSS enthusiasts to meet up and interact, there’s now an OSH User Group (OSHUG) in the UK.  The formation of local user groups would give OSH enthusiasts a place to meet each other, share ideas, and collaborate on projects.

When developing a project in the OSH space, the knowledge barrier can be problematic.  Knowing where to source components of the desired quantity, quality, and at an affordable price can be challenging to newcomers or even to established members of the community working on a new project.

As you scale up your project and perhaps turn it in to a business, new knowledge may be needed which may be completely out of scope for the hardware hacker who started with a weekend hobby.

For example, finding the cheapest manufacturer in China may appear to be a cost-effective way of manufacturing a component, but this may come at the expense of quality, and low quality components can lead to wastage.  Having components produced locally may incur a higher unit cost, but tighter quality control could lead to reduced wastage and savings in the long run.  The knowledge of these facts and which suppliers provide best value is represents an important piece of information to the OSH community.

The key to avoiding lack of knowledge becoming a barrier to participation is as simple as sharing knowledge as its learned.  A wiki of suppliers, public archives of mailing lists or Q&A, a reading list of useful publications, could all go towards solving this problem.

The tricky part is finding a place for this knowledge base to live. Again, user groups could hold the solution to this problem.

The Free and Open Source Software community has 2 figurehead organisations to champion its cause.

The Free Software Foundation (FSF) promotes free software as a means of supporting and protecting computer user freedom. The Open Source Initiative (OSI) operates like a trade body to promote the use of benefits of open source software to developers and users.

There are currently a number of organisations (OHANDA, OSHWA, OHR) that attempt to provide a similar function in the hardware space, although they are not currently as mature in this regard as their software equivalents.  There are competing definitions of what OSH is or should be, as well as a question over whether we need an equivalent of copyleft licensing for hardware, and if this is even possible.

Without recognised people and organisations promoting a vision for OSH, the community lacks a common goal, which could be a barrier to attracting new participants.

OSS Watch was formed to provide funders with a service to support the use and production of OSS in UK education.  Part of the motivation for this was public opinion that publicly-funded software should benefit everyone, by being released under an open source license.

Lacking the focused leadership mentioned above and a clear definition of OSH, public pressure for hardware produced by publicly-funded projects to be open source is unlikely to be forthcoming.  This suggests that the requirement for an OSS Watch-like service for OSH is unlikely to emerge in the short term.

OSS watch would like to thank all attendees of Open Source Junction 4 for participating in these discussions.

While the UK government has for some time now been taking measures to level the playing field for open source software in the public sector, for example by pointing out open source options for proprietary systems, the new Government Service Design Manual goes one step further – mandating a preference for open source for government digital services.

An article in Computer Weekly pulls out some of the key paragraphs of the manual, which state that open source should be preferred “in particular for operating systems, networking software, web servers, databases and programming languages” and that proprietary products should only be used in some specific cases – and in those cases to use open standards to avoid lock-in.

A recent article on the new DCMS intranet service exemplifies the new approach to government web services, with the WordPress-based system costing 90% less than the one it replaces.

(Note that the Design Manual applies to creating government digital services, rather than for procuring software in general.)

One of the most annoying things that can happen to software is for it to become “abandonware”, particularly if its something you rely on.

This is where the original developers of the software cease further development or support, usually to move onto other projects, or sometimes due to a change of employment or other personal circumstances. Whatever the reason for it, the software that was once a key part of your infrastructure ceases to be updated, and over time its going to be less and less viable.

However, with Open Source there is sometimes the potential to “reboot” a software project even when the original developers have moved onto other things.

This recently happened to me with a library called HtmlCleaner. HtmlCleaner is a handy little library that, as the name suggests, cleans up “dirty” HTML and allows you to modify it programmatically. There are other libraries for doing this of course, but HtmlCleaner always had the edge for me due to its light footprint, small number of dependencies, and an API that provided the functions I needed. HtmlCleaner is used in Apache Wookie, for example, to clean up HTML in web widgets and inject additional JavaScript needed for extra features.

Unfortunately, the developer of HtmlCleaner, Vladimir Nikic, had moved onto working on other things, and the last release of the library was in 2010. Then recently we came across a bug in HtmlCleaner that was affecting Apache Wookie.

After some Googling I found that others had come across the same problem, and had forked the project to apply their own fixes. Which didn’t really solve the problem, as you then have to ask yourself which of the forks are viable and up to date, and also run the risk of fragmenting the community.  Wouldn’t it be better if we could get those interested enough to make a fork, to take an active role in the core project?

HtmlCleaner already has a large user community, and the project regularly receives new patches and feature requests; all that was missing at a minimum was someone available to thank users for their contributions, review and apply patches, and manage the releases.

I got in touch with Vladimir, and Patrick Moore, creator of one of the forks, and we agreed to “reboot” the HtmlCleaner project, with Patrick and I getting maintainer access.

I applied a user-contributed patch to fix the bug that was vexing Apache Wookie users, and released HtmlCleaner 2.2.1. Patrick is merging back in the various fixes and improvements that he’d made to their fork, to be released as 2.4. After a gap of two years, HtmlCleaner is back in business!

Of course, in another year or two perhaps both Patrick and I will have moved onto other things too. But if we do, hopefully like Vladimir we’ll be able to hand over to new developers coming from within the community.

Some open source foundations and umbrella projects list dormant projects that can be rebooted;  for example, the Apache Attic is where Apache projects head when they are no longer active, and there are processes for allowing a new project team to restart activity, either by moving the project back into the incubator, creating a fork, or forming a new project management committee.

If projects have been dormant for too long, technologies and frameworks may have moved on so far that reviving them is not a viable option, but in some cases there can be mileage in reviving  one of these projects rather than starting from scratch, particularly if there is still a user community to draw upon.

 (image by _bianconero licensed under CC-BY)

The final day of MoodleMoot Dublin was billed as a hackday with 2 tracks, one looking at Moodle Development and one at LTI.  I decided to take part in the Moodle development track, which really turned out to  be more of a developer meeting than a hackday.

The first topic of discussion was Javascript frameworks.  Moodle’s core javascript uses the YUI framework, which fits very well with Moodle’s modular structure, and can easily be utilised by third-party plugins.  However, newcomers to the community, be they joining a company providing Moodle development, students, or institutional developers almost always arrive with experience in the insanely popular jQuery framework.

While there’s no technical motivation for Moodle to convert from YUI to jQuery, there’s certainly a social motivation to supporting it for plugin development.  There are challenges to be met here – as jQuery development proceeds old features tend to be removed, so plugin developers may target a specific jQuery version.  If Moodle is to include jQuery, it may need to include a mechanism for plugins to use different versions without causing namespace collisions.

At the beginning of the hackday, some bugs were posted for volunteers to fix.  I took up the challenge of fixing bug MDL-33996.  With members of the core development team in the room, this presented the opportunity for a practical demonstration of the bug fixing process I described in my community engagement session the previous day.  Thanks to the developers present and other members of the Moodle HQ team participating remotely, we worked through the process of patch submission, peer review, integration, integration the fix was ready for release by the end of the day.

A topic for discussion in the afternoon was the introduction of a Moodle theme based on the bootstrap CSS framework.  Bootstrap represents a collection of best practice techniques used by front-end web developers and designers, providing simple responsive layouts, CSS-based interface components and a consistent style across browsers.

Initial work has been done to produce a Moodle theme using bootstrap.  The decision now needs to be made has to how deeply Bootstrap’s conventions should be integrated into Moodle.  It’s possible to restrict Bootstrap’s involvement to the themes that are based on it, but given that some areas of Moodle’s markup could do with an overhaul, it could be time to update Moodle’s core output code to follow Bootstrap’s best practices.

It was great to have the opportunity to get a chance to meet some of Moodle’s core developer team face-to-face, and to get an insight into the upcoming developments.   It was also interesting to see the decision-making process of a large open source project at work.  Moodle is primarily a benevolent dictatorship with Martin Dougiamas at the head, but the essential meritocratic nature of the open source community was clearly evident, with those known for contribution in particular areas being called upon to share their opinions and ideas.

I had the fortune of spending most of last week at MoodleMoot Dublin, with members of Moodle developer and user community from the UK, Ireland and across the world.

Throughout the plenary and panel sessions over the 2 days of the main conference, the conversions were often drawn to a common theme: the current hype around Massively Open Online Courses, or MOOCs.  Several high-profile institutions have begun offering free online courses through a MOOC platform, and the phenomenon has recently arrived in the UK with the announcement of FutureLearn.

The MOOC movement could be perceived as a significant threat to a system like Moodle, which is probably why it was such a hot topic for discussion.  If people can teach and learn through a MOOC, what place does an institutional system like Moodle have?

While there was some enthusiasm for the inclusiveness of MOOCs from panelists and audience members alike, if you ask a group like the Moodle community if MOOCs are the future, you’re only ever going to get one answer.

The strongest arguments in opposition to MOOCs becoming a significant threat to the traditional institutional teaching model, rather than a complement to it, was that a MOOC is primarily a package of content.

While MOOCs represent a valuable channel for delivering such content, the existence of such content for independent learning isn’t new.  As Moodle founder Martin Dougiamas put it during one panel discussion, “before MOOCs, we had books”.  Martin was keen to promote a view that MOOCs will augment established e-learning, not replace it.

A common thread of several breakout sessions looked at the performance and scalability of Moodle.  One talk from Moodle partner Catalyst IT discussed a Moodle deployment with 2,000,000 user accounts, supporting 800,000 concurrent users1.

The technology used to achieve this implementation was entirely open source.  Beyond Moodle itself, the set-up described ran on Linux servers (Ubuntu), a PostgreSQL database server, various open source tools for caching data, and the nginx web server.

The PHP interpreter used was PHP-FPM, a special memory-efficient PHP implementation for web servers using FastCGI.

Of course, if you’re implementing a performant, scalable solution you need a way of proving that it works.  For this, the load testing tool JMeter came highly recommended, another open source tool that allows you to simulate traffic to your web server.

Set-ups like this are a prime example showing how open source software is suitable for large-scale deployments – not just in terms of application software but as a whole software stack in combination.

In the morning of the Moot’s second day, everyone gathered to hear from Martin Dougiamas about the future of Moodle development.

A development trend Martin promoted during the keynote was the idea of “Plug-outs”.  Rather than building new features inside Moodle using plugin APIs, it’s becoming increasingly possible to build external systems that integrate with Moodle.

Moodle features web service APIs which can expose Moodle API functions externally over secure, authenticated services.  This allows you to tightly and securely integrate external applications on any platform with Moodle.

Beyond web services specific to Moodle, you can also use the Learning Tools Interoperability standard, or LTI.  The LTI standard allows Moodle to integrate with a variety of tools implementing the standard, providing single sign-on from Moodle to the external tool, and grades to be passed back and stored in Moodle’s gradebook.

However, the integration isn’t limited to Moodle.  LTI is implemented in Sakai, Blackboard, in fact all the major VLEs, open source and proprietary.  This means that any tool implementing LTI can be used with any VLE implementing LTI.

The most exciting and interesting development shown was the upcoming Moodle mobile app.  Unlike earlier developments of an iOS-only app, the new app will be cross-platform and open source.  As well as allowing Moodle content to be viewed on mobile devices, the app will use mobile hardware such as cameras and microphones to allow users to create and upload content.

Interestingly, the decision was made to release the mobile app under an Apache licence, rather than GPL like the rest of Moodle.  I took the opportunity to ask Martin why this decision was made.   The primary motivation was to allow institutions to modify the app to integrate tightly with local systems without requiring them to release the source code since they may want these integrations to remain private.  There was also a secondary motivation of avoiding app store restrictions.  As OSS Watch has discussed previously, some app store terms of service conflict with certain open source software licences, and the Apache licence has been chosen to avoid this.

I’d like to extend a big thank you to the organisers of MoodleMoot, and all of the event’s sponsors.

1 Where “concurrent users” refers to users accessing the site within a 15-minute window.

Following over 10 years of supporting Jisc’s programmes and projects, as a national advisory centre for open source projects, licences, and sustainability, OSS Watch will be moving to a new funding model as of 1st August 2013.

In response to the Wilson review of Jisc, the latter has confirmed that it will continue to support OSS Watch until 31st July 2013 but this will be its last year of core funding. This provides us with a new opportunity to model OSS Watch to meet the needs not only of HEIs but also units outside of HE & FE, including both the public and private sector.

We are currently finalising our new business model; our goal is to expand OSS Watch’s long established portfolio of services but on a chargeable basis. Moreover we are looking at how OSS Watch can be combined with Oxford University’s other activities in the open arena (open education, open access, open data) to present a truly unique offering and centre of expertise.

We would be very interested to hear from you if you are interested in future collaborations, research projects, or other activities; or believe that OSS Watch’s traditional services (advice on open source projects, products, licensing, sustainability, etc) would be of interest to you in the future.

(The original press release for this post is on the OSS Watch website)