Wookie: A case study in sustainability

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.

Wookie graffiti

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)

More open source options for education

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.

Guardian recommends open source skills as an employability bonus

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.

Trademarks and FOSS

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.

Is Tomorrow’s World an Open Source one?

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.

Photo of Liz Bonnin, Horizon presenter

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.

Koha: a case study in open source project ownership | opensource.com

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.

Open Source Junction Hardware Projects

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.

ColorHug

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

PanStamp

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.

Remote Care Package

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.

Stellar Computer System

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.

Cellular Automata

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

Open Source Hardware Communities

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.

Tools

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.

Geography

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.

Knowledge

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.

Leadership

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.

OSH Watch?

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.

Rebooting Open Source Projects

Restart ButtonOne 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)

MoodleMoot Hackday

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.