Open source education - ensuring students develop the skills they need

Published by stevelee on July 3, 2009 in Uncategorized. 0 Comments

When I first became involved with Mozilla through working on a Mozilla Foundation accessibility grant, I quickly discovered the impressive open source educational work at Seneca College in Toronto, lead by David Humphry and Chris Tyler. Students on the computer science course get the enviable opportunity to work on projects that immerse them directly in some of the most successful open source development communities, contributing to programs such as Firefox, Thunderbird, Open Office and Fedora (Linux).  These projects are not just academic exercises, rather they are strategic for the open source projects, and students contributions are accepted into the projects. As a result students get incomparable experience working on large code bases and in the process acquire the open source software and community development skills that are highly sought by companies all over the world.

This work started with Seneca introducing Mozilla technology in their courses and soon Mozilla joined in, with key people giving lectures and making themselves available to the students. If you visit Seneca’s Mozilla IRC channel you will find a vibrant community where students, faculty staff, Mozilla staff and volunteers are busy discussing issues, working on projects and having fun.

This morning I spotted a tweet from Mark Surman, Mozilla Foundation’s executive director,  that linked to this excellent paper by Chris Tyler explaining how Seneca approach open source education.

OSS Watch, like Seneca and Mozilla are serious about open source education as the way to address the skills shortage. Along with the others members of the Teaching Open Source collaboration we are working to ensure students, educational institutions and industry alike acquire the open development skills that are so critical for much modern software development.

Innovation through Open Development

Published by Ross Gardler on July 2, 2009 in Development and Community. 0 Comments

In my last post I argue that open development can both reduce costs and improve quality. Today, Steve Lee pointed me to an article in Business Week that illustrates the point very well.

The article identifies Ken Saunders, a 41-year-old, legally blind volunteer for Mozilla as a prime example of the kind of third party contributions that are key to the success of open development projects:

Saunders is among hundreds of people who donate time and skills to Mozilla, the Mountain View (Calif.) company that releases Firefox and other open-source software. Even as Mozilla’s internal staff has grown to 250, from 15 in 2005, an army of volunteers still contributes about 40% of the company’s work, which ranges from tweaks to the programming code to designing the Firefox logo.

Innovation in open development can happen within the core project team, but it can also happen at the edges, where people with different objectives and interests see value in the projects outputs. According to the Business Week article Mike Beltzner, who runs the Firefox project, says that open development projects need to “allow people to innovate and to explore and [give them] the freedom to do what they want along those edges—that’s where innovation tends to happen in startling and unexpected ways.”

The article also discusses some less successful attempts at open development, highlighting some of the good and bad approaches to rewarding and recognising volunteer contributions. A recent case study on TexGen, published by OSS Watch, illustrates how the open development model can be used to apply to even the smallest niche area project.

Software Sustainability

Published by Ross Gardler on June 30, 2009 in Development, Discussion and Community. 0 Comments

The EPSRC recently issued a call titled “Software Sustainability“. This topic is something that is close to the heart of OSS Watch, so naturally OSS Watch submitted a bid (and, in fact, were named as partners on a number of other bids).

Collaboration is the key

OSS Watch have been acutely aware for some time that the “standard” approach to software sustainability in our sector is to “throw more money at it”. Indeed, most of the bids into this call, that we are aware of, take this approach. At OSS Watch we take a longer term view. We believe that sustainability is about reducing long term cost through collaborative development, this requires a short-medium term investment in developing collobarative software development skills. Unfortunately, our sector is more accustomed to competition for grants than to collaboration for value for money.

Evidence of this can be seen in the OSS Watch experience during the writing the our EPSRC bids. We were approached by a number of people who refused to allow us to talk to others about their plans, a ludicrous situation since some of the gaps in experience in one proposal could be closed by bringing in another member of our network. In other cases we invited representatives of potentially competing bids to view and discuss our own bid in order to find points of collaboration. Some joined our open mailing list  and viewed our draft proposal in the wiki but not once did they contribute, they didn’t even acknowledge our invite. In other words they wanted to take, but not to give.

The end result of this competition is, in this case, a number of less than ideal bids. This prompted OSS Watch to sumbit a bid that explicitly called for the EPSRC to match our own bid with another with, in the funders eyes, a suitable domain specific expertise. Assuming that our bid is seen as valuable in itself we look forward to sharing our expertise with one or more of the other bid teams.

How do we collaborate?

It is our belief that to create sustainable software that survives between one development team (i.e. grant) and the next (i.e. another grant) we need to change this culture of competition into one of collaboration. In the non-academic sectors there are significant examples of this working on both large and small scales.

The problem with this approach is that project team currently expect their own chances of survival to be dependant on their “ownership” of the outputs and knowledge acquired during the first grant. Indeed OSS Watch are an example of this. As OSS Watch manager I am responsible for ensuring we have enough grant funding for over five full time staff. If I encourage others to enter our space am I putting my team at risk?

I don’t beleive so, my team have a very specific set of experiences and skills. Collectively we cover most aspects of open source software development. Our network reaches far and wide into the academic and non-acadmic open source communities, but we are not omnipresent. By being clear about our specialisms and recognising other groups expertise we should be able to increase the amount of grant money we recieve as we will get access to more varied pots through our cooperation. What the sector needs to realise and accept is that by being the expert one will be invited to participate in more projects not compete for less.

Whilst OSS Watch’s experience in this EPSRC bid would seem to simultaneously support and undermine this argument, it is our belief that in the long run cooperation is where value and sustainbility lies. There  are examples of this happening with niche software produced in the acadmic sector too. For example TexGen, a project at University of Nottingham has recieved significant additional funding as a direct result of the openness of their software outputs.

Sucessful collaboration means fully open collaboration

Unfortunately, TexGen is the exception rather than the rule. Even where collaboration is the goal, our sector still tends to artificially limit membership of the community to those who are funded. This can be seen in the Community Source model, popular in large US projects which excludes some parties from participation and therefore limits the sharing of both costs and rewards to a smaller group than is necessary.

The community source model aims to add a level of control to open development projects that it is believed does not exist in true open source. However, I would argue that this is a lack of understanding of the open development model rather than fact.

My own experience shows me that there are decision making models in open development that allow for the level of central planning and control needed in major projects whilst still ensuring the doors are open to anyone who wishes to contribute in a sensible and construcitve way. Indeed, if this were not the case then open source, and sustainable, products such as Eclipse, which is found at the heart of a large number of varied third party tools, would not exist.

In order to demonstrate this to be the case OSS Watch have been working with some experienced community source practioners in the Matterhorn Project. Together we have drawn up a governance model for this new project which appears to satisfy the control concerns of the funders whilst also satsifying OSS Watch’s concerns about keeping the commuity open.

At first glance this model may seem somewhat heavyweight for a smaller project. Therefore, OSS Watch have also worked with other parties to develop a much lighter touch governance model suitable for “rapid innovation” projects that are funded for just six months.

Those of you who read these models will realise that they are essentially the same model, it’s just that one defines more formal roles than the other since it has more initial stakeholders. This means that should the rapid innovation project be succesful it’s model can grow to accomodate a growing, and as yet unknown, community. It is this growth that is the start of sustainability through a collaborative development model.

The practice of open development

Now that OSS Watch have started to show that closed communities are not required, the next step is to encourage people to develop their software in such a way as to ensure non-community members are empowered to participate. It is these third party contributions that spread the cost of development across multuple financial pots and thus reduces centralised risk.

We recognise that policy is all very well but it is practice that matters. The adoption of open development practice requires a significant cultural change, but this is a change that our research shows is desired byenough practitioners to make it viable.

OSS Watch argues that funding projects to experiement with software ideas and then spending more money to “harden” the few that have promise is wasteful. We believe all software should be developed openly from the outset. By doing this the cost of sustaining software that succesfuly meets user needs is decreased since initial outputs, of all kinds, are reusable. Where software does not meet user need, as can often be the case in research software development,  the increased level of collaboration and awarenees within the community serves to increase the chances of success in future projects. This is because the community is sharing not only the “hardened” successes, but also the lessons learnt in other projects.

The ÆGIS 1st Pan European open accessibility Workshop

Published by stevelee on June 12, 2009 in Software, Development, Accessibility, Strategy and Policy, Standards and Community. 0 Comments

To be honest I’m enthusiastic about the potential of the European ÆGIS project which launched last week. I see the blend of open source and accessibility, open accessibility, as having the potential to provide the most appropriate solutions for users of accessibility and assistive technology. So I’ve spent the last few years developing and promoting the concepts of fair access to all and user engagement whenever I get the opportunity. This has brought be into contact with enthusiastically dedicated  people and projects. The scale and scope of ÆGIS gives the impression open accessibility is now coming of age. The strap line of ‘Open Accessibility Everywhere: Groundwork, Infrastructure, Standards’ indicates the wide scope of the project which aims to use open source, open development and open standards to ‘enable people with disabilities, the elderly and anyone else who is disadvantaged when using Internet services, Desktop PC or Mobile phones’. It will do this by providing developers with a framework, architecture and toolkits, whilst also creating end user applications. 4 pilot studies will inform the subsequent development phases.

The Pan-European Workshop completed the launch week activities at Research In Motion’s Slough Offices and shared the proceedings with Raising The Floor an initiative by Gregg Vanderheiden and Jim Fruchterman to bring together all parties working on web accessibility, again using open practices. Greg has been involved in accessibility for many years and in his Introduction, Peter Korn, technical lead on ÆGIS sited Greg as his primary mentor. Peter in turn has been very active in open accessibility, especially the GNOME desktop which is used in Linux (e.g Ubuntu) and Sun’s Solaris. Peter along with Will Walker has taken a key role in orchestrating the  resources of their employer Sun to bear on making GNOME a focus of much open accessibility work, including infrastructure, the Orca screen reader, GOK on screen keyboard and collaboration with the Firefox web browser accessibility team.

In addition to hearing more about ÆGIS, the workshop offered the opportunity to catch up with some of the collaborators from the Ace Centre, OATSoft.org, aIDEAS & Mozilla as well as being something of a ‘tweatup’ for those who follow each other on Twitter, including Henni of Opera, Steve Faulkener and Gez Lemon of TPG and Davis Sloan of the University of Dundee. There was woefully little time to chat and I completely missed David Banes of AbilityNet and David McKay of Inference Labs, Cambridge (Dasher is an alternative text input program). I did finally meet Jutta Treviranus, director of ATRC at University of Toronto. Jutta is the boss of long term open accessibility developer David Bolter (e.g. GOK, dojo, ARIA), and we also heard the news that David is taking a years break from ATRC to work on Mozilla core accessibility with Maroc and Surkov.

Due to my failure to understand the scale of the map I arrived after the start having wondered up and down the batch road. The first few talks by M Gonzalez-Sancho (EU Commision ICT for inclusion, information and media Directorate General) and E Bekiarias (CERTH-HIT) provided high level views of the EU’s inclusion policies and AEGIS (£12.6M funding) as well as feedback from the previous days user forum.

Peter Korn then gave a technical overview with demos of existing applications including old friends such as the accessibility APIs, GOK, Orca+eSpeak, Dasher and Accerciser. In addition Peter showed an as yet unreleased simulator of visual impairments such as macular degeneration.

Dr Bekiarias then presented the AEGIS use cases which appear to present a reasonably representative and useful range. I was pleased to see symbol support in OpenOffice.org along with synthetic voices. As Simon Judge pointed out the desktop had little for AAC and switch users but  there is more on the mobile platform.

After an all too brief lunch, Dr C Galinski (InfoTerm) gave a presentation on structured content standards. This was followed by a very effective talk by Greg on accessibility overall and Raising the Floor. He made the point that what we do determines if ICT is a blessing or a curse to many users. He provided a clear analysis of the ways of providing accessibility (adjust interface, provide alternative interface, select alternative or download new interface on demand) and asserted that the accessibility API’s are the only real chance for an affordable and lasting strategies for flexible interface options (and I agree). He also considered reducing cost to users and the part OSS plays, seeing this as enabling more direct paths for the transfer of research and allowing the public coverage of costs other than licences. he also suggested we might like to consider free public access (cf public/private schools) and the need to fund more than research - e.g hardening, awareness, support.

Before the panel discussion Peter announced the Open Accessibility Everywhere Group. The desire to bring together all interested parties including developers, researchers and users and so facilitate exchange of ideas it echos the original motivations that underly Oatsoft.org and later Project:Possibility. While Oatsoft’s funding was only for an initial evaluation phase we can hope that OAEG will succesfully fill this important community role and so help us push the open accessibility envelope. There is an overlap here with Raising the floor that will need to be worked out, though AEGIS adds desktop and mobile accessibility to RtF’s focus on web accessibility.

I was pleased to see a place for the open accessibility projects I have been personally active in. In addition to key projects such as Mozilla, GNOME and NVDA I saw some potential for those I have been closely involved in as a developer; Simon Judge thought Maavis has something to offer in many use cases, and the straight-street.com open symbol set has much to offer. Jambu may also be useful as a starting point for some work. I’m not sure about PowerTalk as it relies on MS technologies but at least that is now included in the EduApps USB stick collection. Greg again mentioned his interest in OATSoft.org as providing the master list of projects, though the announcement of the OAEG seem to indicate it would be providing similar functionality after all.

So all-in-all a useful workshop but perhaps too many presentations with too wide a scope; I would have liked more networking time. ÆGIS is an exciting project and a serious opportunity for the benefits of open accessibility to be realised by users and developers alike. There is a lot to be done and good management will be need to ensure it delivers, but building on open development gives it a very good foundation for success. I’m looking forward to being involved as well as watching what happens.

I’m greatful to Ross Gardler (OSS Watch manager) for being so supportive of open accessibility and providing me opportunities to make it part of OSS Watch’s portfolio of experience. My first project was AccessApps and we spent Tuesday in a highly constructive consultation with the Maavis project, working out ways forward by embracing open development.

That reminds me I have an article on open accessibility to take though OSS Watch’s thorough quality control process.

Google’s Video Games

Published by Rowan Wilson on June 11, 2009 in Development and Legal. 1 Comment

HTML 5 - the next version of the language used to create web pages - is due to be finalised somewhere between 2010 and 2012, depending on whether you believe the W3C or the WHATWG, the two groups who are contributing to the language specification. One of the expected benefits of the new version is that it will allow page authors to reference and embed videos in their pages without requiring end users to have a specific browser plugin installed. At the moment, Adobe’s Flash and Apple’s Quicktime are the most popular methods for getting video into web pages, but this irks many web purists who feel that the requirement to install these plugins undermines the goal of a truly ‘open’ standards-based web. After all, while web video playback depends upon vendor-specific software, the vendors in question have enormous power to control which browsers and operating systems they will support and therefore which will be widely used. There is of course a powerful pragmatic counter-argument to this, which says that the success of the web is driven by adoption not contemplation and any solution that has been generally adopted has to be considered the correct one. If you are a business wanting to outshine your competitor’s web presence, you are likely to adopt whatever is the most attractive, eye-catching and available technology at the time without worrying to much about high-minded ideals of openness. Into this argument, HTML5 - and specifically its <video> tag - strides to resolve the question once and for all.  That at least was the idea. 

 Proprietary plugins are not the only things that threaten the ‘open’ web. Patents covering the use and creation of certain types of media file are also a problem. It would be fairly pointless to sweep away proprietary video playback plugins if you then replace them with in-browser functionality that requires a patent licence to actually include. Therefore as well as mandating that compliant browsers should be able to playback video URLs indicated by the <video> tag, the HTML5 specification originally directed that every browser should - at the very least - be able to decode the ogg theora multimedia encoding format. Theora - named after a character from Max Headroom an 80s sci-fi TV drama - is an open standard for the encoding of video which is of a similar quality to the patented H.264 MPEG4 encoding standard used in Quicktime and on many Blu-Ray High Definition video discs. Theora derives from work done by technology firm On2 who have granted a worldwide royalty-free licence to anyone who wishes to incorporate theora encoding and decoding functionality into their products. The software for actually doing the encoding and decoding is released under the open source BSD licence. It all sounds great I’m sure you’ll agree - patent-free video (and audio - ogg has a project called vorbis that handles that) playing right in your browser and no-one has to install a plugin or pay a patent licence.

 Unfortunately Apple and Nokia - companies that would be creating HTML5 browsers in the future - lobbied successfully to have the theora/vorbis mandate removed. Nokia puzzlingly claimed(pdf) that theora was proprietary, and less puzzlingly pointed out that the format had no accompanying Digital Rights Management implementation that might help providers make money from their content. Apple argued that although the On2 patents in theora were licensed royalty-free, there was no guarantee that there were not other video-related patents out there that might be infringed upon by theora (particularly submarine patents - meaning patents that have yet to be fully published for administrative reasons but which it is still possible to inadvertently infringe). Apple also claimed that there were few-if-any hardware implementations of theora decoders, meaning that low-powered devices like mobile phones could not incorporate a specialised decoding chip to take the pressure of video work off their overworked central processors and sagging batteries. Open web enthusiasts pointed out that no video format is free of submarine patent concerns, and mandating theora in HTML5 would almost certainly mean that there soon would be theora decoding hardware available. Some uncharitable commentators also pointed out that Apple held one of the essential patents for MPEG4 decoding, and so stood to make money from additional licence sales if MPEG4 became a common format for the contents of the HTML5 <video> tag. 

So the issue was already a vexed one when last week Google announced on the WHATWG mailing list that their support for the <video> tag in version 3 of their browser Google Chrome was going to use LGPLv2.1-licensed free software video library ffmpeg to decode both theora and MPEG4 H.264. Why was this controversial? Well as I mentioned above, H.264 is subject to a whole cupboard-load of patents, and anyone who looks like they have a bit of money would be well advised to get a comprehensive licence from the relevant group or be prepared for a writ on the corporate doormat one morning. Clearly anyone with a pocket-book the size of Google’s would have taken this essential step. However even doing this might well not allow you to distribute ffmpeg safely. The LGPLv2.1 - like the GPLv2 - contains a clause which aims to prevent the software it covers becoming subject to additional responsibilities and fees. This clause (section 11) reads: 

If, as a consequence of a court judgment or allegation of patent infringement or
for any other reason (not limited to patent issues), conditions are imposed on
you (whether by court order, agreement or otherwise)that contradict the
conditions of this License, they do not excuse you from the conditions of this
License. If you cannot distribute so as to satisfy simultaneously your obligations
under this License and any other pertinent obligations, then as a consequence you
may not distribute the Library at all.  For example, if a patent license would
not permit royalty-free redistribution of the Library by all those who receive copies
directly or indirectly through you, then the only way you could satisfy both it
and this License would be to refrain entirely from distribution of the Library.

This clause is generally understood to mean that paying for patent licences to distribute LGPLv2.1-licensed code is impossible; once you pay for the licence you lose your right to distribute, so it’s never worth doing (and this in turn acts as a deterrent to patent owners looking to get per-copy royalties on LGPLv2.1- and GPLv2-licensed software - even if you win the case against the distributor, you kill the product and will get no royalties going forward). Nevertheless, Google’s lawyers seemed to have found a way through waters which had previously been thought unnavigable. As the argument on the thread continued, it emerged that Google’s approach had been to seek a patent licence for Chrome itself, not the ffmpeg library that was actually doing the video decoding. The LGPLv2.1 is designed to allow code it covers to co-exist in an uneasy peace with code covered by any other kind of licence, including patent licences. In this was free software libraries could be used with proprietary software in a way that would be impossible if they were covered by the full GPLv2. Google argued that as long as they never sought patent rights to use ffmpeg, no-one could accuse them of not passing on those rights to others in a way that ffmpeg’s licence mandated. All their permissions to use patents rested with Chrome itself - however it chose to do the decoding. 

 Now this is a sly move, and not one that has been attempted in as high-profile a piece of software as Chrome up to now. Will Google get away with it? Well that question really reduces to the question: Who might try to stop them? In this case Google Chrome is relying on licences from the MPEG-LA for the patents used to decode MPEG4 (and possibly theora if they want to rule out any future challenges from MPEG-LA on that score) and a software licence from the ffmpeg project. The likelihood is that Google have paid well for complete coverage from the MPEG-LA, and so a challenge from that quarter seems unlikely. What about the ffmpeg project?  Well they clearly explain that they have no specific knowledge of any patents infringed by distributing ffmpeg. Of course, everyone is aware that the project very likely infringes on many patents in the H.264 patent pool at the very least, but time and experience has taught programmers operating in patent-rich problem domains to never read the relevant patents. It only increases the likelihood that you will infringe upon them and increase the damages if it can be shown that you knowingly infringed. What this means for ffmpeg is that it would be very difficult for them to argue that Google is not in compliance with the LGPLv2.1 for ffmpeg because they have licensed some patents ostensibly for use in Chrome. To do so they would have to explain exactly which of the patents licensed were in reality embodied in ffmpeg, and would therefore trigger Google’s responsibilities inder the LGPLv2.1. This could be seen as an unwise move for ffmpeg. With neither the MPEG-LA or ffmpeg likely to question Google’s actions, it seems likely they will get no substantial challenge to their actions.