The announcement about Symbian going open source made me watch an introduction video flagged by my colleague Rowan, who has written about open source in mobile devices.

What I heard, among others, was that developers are encouraged to contribute to the open source platform, and in the final section (3′45″) that Symbian’s governance model allows virtually anyone to be part of the working groups and councils and have a say about their future direction. This looks good, I thought, let’s check further.

There is a wealth of information on Symbian’s developer site, including another video suggesting how users and developers can get involved.

The contribution process includes both general issues about contributing source code and more specific ones, such as how to contribute a fix, an enhancement, an extension, or how to start a new Symbian-related project.

In a nice piece on the wiki I also found things very much in the spirit of how we talk about open development and the process of building open source communities:

“Contributors are also users (which is one reason why they are motivated to meet the needs of the users) but contributors want a say in the roadmap so that they have a chance of influencing it in directions that benefit them and they want to be able to get their contributions accepted into the project. Contributors may provide code for bugfixes and new features (the most obvious form of contribution) but they can also contribute support services, translations, documentation etc.”

Community-wise this looks like a nice step to open source for Symbian. Let’s wait and see.

It started with an application that has been built by Nick Burch at the Apache Software Foundation to facilitate the search of geographically ‘nearby people’. He made this little Django application available via a Subversion repository with an Apache licence.

Linking people and projects is also one of the aims of the project registry framework Simal that OSS Watch is involved in. On Simal’s public demo site there is a collection of projects and people working on these projects. Besides doing development work on the Simal application OSS Watch is starting to use the registry more often in our daily work. Unfortunately, we recently failed to find out about a project that was run at our institution, Oxford University, even though it was present in our public registry.

When I realised Simal was lacking functionality that had been useful for OSS Watch, i.e. to find nearby projects based on location, I created issue 263 for Simal, dumping my thoughts about possible solutions, among which the ASF application on nearby people.

A key problem in adding this functionality was to have the geo-location data of the institutions that are in involved in the projects. This prompted Ross to reach out to his wider community to see whether anyone had tackled this issue.

The first and very useful suggestion on this matter was from Paul Stainthorp who pointed to a list of UK universities and their geo-location, which is maintained at Wolverhampton university.

The second one was from Sam Easterby-Smith who pointed to a list on Wikipedia. That was a good one, as Wikipedia is quite complete and geo-tagged, so we would have the data from that source if only we had a convenient way of extracting it.

The solution to that problem is to use DBpedia and it was suggested both by James, who added a comment to the issue in the tracker, and by Wilbert Kraan on Twitter. DBpedia is a community effort to extract structured information from Wikipedia and it provides a public SPARQL endpoint for querying Wikipedia data. We can conveniently query that endpoint for a list of the geo locations of al UK universities and add that data to our Simal repository.

So within one working day we have a solution to the main problem, getting the geo-location data. But Ross’s discussion with someone already doing this revealed that they are manually creating the data, so they can potentially benefit from our search and automate it, if they want to. Furthermore, someone on Twitter noticed our search and he indicated that he would be interested in the solution, so potentially more people and/or projects can benefit. Furthermore, since everything happened completely in the open, even more people have the opportunity to find our solution and use it in their own problem space.

To me, this is a perfect illustration of the power of community. There is just so much that we all collectively know and by having your project run out in the open, freely accessible by everyone, enables you to tap into the collective knowledge of many experts. If this is not a reason to use the open development method, I don’t know what is.

The community is the lifeblood of the project and as such should be protected and nurtured. One of the most important aspects of this is the licensing of the project. There are several types of open source licence available; the choice will depend on the future plans for the software.

Contrary to the traditional concept of a licence, open source licences are designed to increase rather than restrict the freedom of the licensee, to encourage contributions to its functionality by modifying the source code. The GPL, for example, is a copyleft licence designed to ensure that the code it covers remains free and open source by dictating that derivative works, should they be distributed, inherit the same licence as their parent project and cannot be incorporated into non-FOSS products. At the other end of the spectrum is the permissive licence, such as the Apache Software License. Unlike copyleft licences, it allows the inclusion of FOSS in non-FOSS projects and the licensing of derivative works in any way the distributor pleases.

What implications does the choice of licence have on community development? Copyleft licences may restrict the uptake of the code, and therefore the size of the community, because of their ‘viral’ nature: they are seen to ‘infect’ all derivative software with the same restrictions, thus limiting the business models available to projects building on that code. Since copyright holders have additional rights over licences, centralised ownership of copyleft-licensed materials can add additional community concerns because of the scope for ‘abuse’ of that community. Witness the case of Oracle’s planned buyout of Sun, which would make Oracle the exclusive holder of the open source MySQL copyright and trademark. This could have potentially damaging consequences for the project’s future, and possibly result in higher prices for database software.

Permissive licences, on the other hand, encourage greater uptake of the software and wider participation from outside the project because they don’t dictate terms under which derivatives can be distributed. Thus, relinquishing control over what can be done with the code fosters community development, which in turn increases the opportunities for innovation. Permissive licences allow almost any business model except dual licensing and are therefore more appealing to commercial developers.

The contrast between copyleft and permissive licences is illustrated by SpringSource’s recent decision to move from the GPL to the Eclipse Public License (EPL) for its OSGi application server. The company originally chose the GPL because, in the words of CEO Rod Johnson, ‘there’s a lot of technical innovation under the hood [and] if we’re giving that technology away in open source, we wanted others who build on it to also give away results in open source’. The move to the EPL suggests that the company recognises the value of a wider adoption of their technology through more permissive licensing and collaborative community development.

However, permissive licences don’t ensure the ongoing freedom advocated by Richard Stallman, which underpins the FOSS philosophy. Significantly, though, Stallman is himself beginning to accept that they are sometimes necessary, as evidenced in a recent article in which he admits to having mixed feelings on selling licence exceptions. Could this shift in Stallman’s thinking be evidence of a fundamental change in the broader licensing landscape?

The Sahana Software Foundation are looking for additional developers to help with Sahana, a disaster management tool. They need to continue to build an information portal that is seeing increased interest and usage to assist organisations responding to events in Haiti. Information on the work underway can be found on the Sahana Haiti response Overview page.

The skills they are primarily looking for are (you don’t need them all, any will do):

•  Python - the main development for SahanaPy is Python (we’re not using PHP for this instance)
•  web2py - Sahana uses the web2py enterprise framework for SahanaPy (I’m told it is fairly easy to learn if you’re used to Django)
•  OpenLayers
•  jQuery

To find out more and offer your help please jump onto #sahana on freenode. Please give as much or as little as you want.Some of the core devs have been working really long hours the past 5-6 days, and any additional resource would assist us greatly, particularly as the effort is really starting to get some interest, traction and coverage, which leads to more and more feature requests.

Thanks for reading this far - please consider giving a few hours of your time to help out, if you can.

The workshop was introduced by Steve Lee, who gave a high-level overview of the topic, focussing on the open development model and what a strong community looks like, as distinct from the open source code that they may be working on. The need for a wide and diverse community of contributors was stressed: not just programmers but contributors with all skills are important, including artwork, marketing, testing, documentation, etc. A good community should be able to sustain itself and cope with people leaving and new people joining. The key to this has to be transparency: all the history and previous decisions should be open for new contributors to review, which will prevent settled issues from being re-raised by people who missed the original discussion.

The licensing and legal considerations of an open project are very important for the community. Contributors need to be sure they have the legal right to give their contributions to the project and if necessary modify the terms of non-disclosure agreements or contracts of employment that could otherwise cause problems down the line. Some projects have contributor license agreements to protect the provenance of contributions; this is something a new project should seriously consider. To provide more information on this OSS Watch has produced a briefing paper on contributor licence agreements.

There is a wide range of free and open source tools for managing a distributed community-based open development project. Most community projects have some kind of shared communication system such as a mailing list or forum; critical to this is the history or mailing list archive being publicly available to new contributors. If the code is open but the communications are closed, the community will struggle to grow. A version control system should be used right from the start of a project to track who contributed which bits of code. A structured system distinct from the project communication system is used for tracking bugs.

Sebastian Brännström of Symbian treated us to a beautifully designed set of slides for his presentation, on how Symbian is moving from a very closed platform to an open development model. Sebastian has written open source software to run on Symbian and now works in delivery management for the Symbian foundation. In terms of governance, the foundation is set up as an independent not-for-profit organisation, which facilitates development but doesn’t actually do development as part of its activities. The foundation started with 12 member organisations, which has now risen to about 180, and has 90 employees. In order to give structure to the governance of such a large project it created four councils to control different aspects of the platform: features and roadmap; user interface; architecture; release management. An interesting aspect was the deliberate selection of structures that make it easy for anyone to influence the direction of the project, not just the larger members such as handset manufacturers.

Sander van der Waal told us about his work with the Apache Felix project. Apache Felix is an implementation of a standard framework called OSGi which defines a modular system for Java applications which amongst other things allows parts of a system to be updated whilst it is running, a powerful feature for highly reliable applications. When Sander got involved in Apache Felix it was in the Apache Incubator, which is a part of the Apache project where young projects are guided through the community building process. His project team started by reading and following the mailing lists for some time before joining in. They found it important to keep all communication on the list. This included communication between colleagues, even where a direct communication option was available, as it was better to keep it to the list so that the information could be shared and archived. Sander went on to explain how the integration of an issue tracker and revision control system is used in conjunction with a mailing list, allowing visibility of who contributed each line of code and which issue each change addresses.

Mark Johnson of Taunton’s College gave a talk on getting started in joining a community from a development perspective. Mark started contributing bug fixes to the Moodle virtual learning environment and took us on an introspective tour of the sequence of events as he progressed from using and administering a Moodle installation to being a part of the community that produces it. Collaboration is an important aspect of open dev, and Mark thinks, if done properly, a collaborative development process produces the best results. As well as raising his personal profile, Mark has benefited from the quality checking and motivation that working with others provides. Mark went on to warn of the dangers of over-collaboration: soliciting opinions from too many people leads to confusion, and bad design. He suggested limiting how widely you consult in discussion phase, produce a prototype/proposal and then have that critiqued; the existence of a tangible contribution limits how widely people’s suggestions can range. You don’t need to please everyone all the time, the objective is writing great software and some healthy disagreement and debate is a part of this.

Steve Lee then kicked off a session on evaluating the openness and sustainability of open source projects using an online form developed by OSS Watch.

This was an audience participation activity, which gave me a bit of a break from the live blogging and a chance to take a quick photo of the audience as they gathered in clusters around an assortment of laptops. I counted three Macbooks, four running some kind of Linux, and three on Windows. Everything points to a more diverse computing landscape over the next few years, with different devices talking to each other using open standard protocols and formats.

I found the results of the activity very interesting in that the audience had no problems choosing projects they were working on or in their own specialist area of interest. Nobody attempted to evaluate the projects with the broadest appeal, such as Firefox and OpenOffice.org. I think this, and the range of resulting scores, points to the evaluation having good practical value for the OSS Watch sector.

The event closed with a panel session in each room, I will pick out a few topics that were covered; there is more in the transcript. The first questions were “Should a project accept all contributions” and “does it matter if a contribution is ignored?” All the panel members stressed the importance of managing contributions and responding to contributors; if a contribution is not used it is critical to provide feedback so that the next contribution meets the required standards for acceptance. Sebastian Brännström said that taking contributions seriously was critical to keeping users and the community happy.

The discussion moved on to the issues faced by smaller projects with a team of core contributors. In order to increase the number of active contributors projects should focus first on increasing the number of non-contributing users and lower the barriers to new contributors, helping users progress to being contributors.

The final question was “What pub are we going to?” the answer to which turned out to be the “Far From the Madding Crowd” where discussions continued into the evening.

Wookie provides an implementation of the W3C widget standard and allows you to write, deploy and manage W3C compliant widgets easily. The project is also working on implementing extra modules, such as a Google Wave Gadgets API. To increase cross-platform interoperability, several plugins have been written to integrate with other systems, such as Moodle and Wordpress.

This event is free of charge and invitation only. However, we have three open places left for interested developers. General development skills are required, but you don’t need to have specific experience in building widgets. If you are interested we welcome you to contact us on info@oss-watch.ac.uk and let us know why you should to be there. If you would like to know more, details about this all day event can be found on the event page.

One of the reasons we hold this event is in preparation for the dev8D developer days. During that event we will be doing more widget development in a Wookie hackathon and we want to gather some more skilled widget developers for that hackathon. Therefore we expect people who come to the Wookie training day to also attend the dev8D days. However, don’t hesitate to contact us for the Wookie training day if you can’t make it to dev8D.

One important feature that may not be obvious from using the toolbar, is that the Accessibility Team at the University of Southampton Learning Societies Labs, developed the toolbar for TechDis while also making it an open source project.

By supporting this TechDis have increased the opportunity for sustainability by allowing the project to continue to evolve while attracting contributions from others, whether they are users submitting bugs and feature requests, or development teams interesting in using it in new applications. OSS Watch’s advise on open development practices has enabled EA Draffan to include these in her management of the project. In addition Seb Skuse, the lead developer, has used established open practices in his daily work on the project.

Seb attended one of the OSS Watch workshops on engaging with open source and found what he discovered useful in ensuring barriers to contribution are been minimised. The Accessibility Team have been heard to say that they enjoy working on an open source project and I am impressed with their eagerness to understand and apply the principles.

Working with them has been a very positive experience. They are undoubtedly a group to watch as they steadily increase their portfolio of open accessibility projects with wide application. Tools that demonstrate open innovation in provision for users of accessibility in education and beyond, by turning new ideas and research into solutions which provide practical benefits.

Download and try the Toolbar and let the team know what you think. You will find the team most welcoming of your ideas or other contributions.

This has been a very hard piece to write. We felt we needed to talk to as many people as possible, we needed to sift through  significant amounts of Fear Uncertainty and Doubt along with unnecessarily emotional responses.

Things weren’t made any easier by the fact that every time we felt ready to publish something else heppened that seemed to change the story somewhat and we had to return to our sources for more observations.

During our research for this article OSS Watch have been accused, by an OSI board observer and ASF Member, of being “surrogates” for Microsoft, whilst Tony Hey (Corporate Vice President of External Research, Microsoft) privately expressed concern that OSS Watch was “encouraging academics to use the GPL.” Simultaneously, various free software representatives have pointed out how “naive” they believed us to be by even considering the idea that Microsoft may have genuine intentions with respect to engaging with the free and open source community.

As a non-advocacy advisory service we tend to think that if all sides in a debate believe we are in the wrong, yet all are still talking to us, we are probably doing something right. Certainly none of them can claim us as their own.

Given all this input what did we conclude?

Well, as you would expect, the conclusion is far from clear. On the one side we have the Stallman’s (Free Software Foundation) view that “these free programs are meant specifically to prevent the world from freeing itself from non-free software”. On the other side we have Erenkrantz’s (The Apache Software Foundation) view that “every positive and constructive engagement Microsoft has with the open source community (and vice versa) … will continue to chip away at the old perceptions”.

Furthermore, whilst Microsoft may be making concessions to open source and are happy to play with open source when it suits their needs they are also willing to use other methods where it best suits their business. For example, on patents Darren Strange (Head of Open Source Engagement, Microsoft UK) says “Patents drive innovation and they drive openness actually.”

Our own conclusion is that “Microsoft is not simply an unchanging monolith.” The article demonstrates that things within Microsoft are changing. Naturally they are changing in ways that benefit Microsoft as a business, but the good news is that some of these changes also benefit the world of free and open source software.

Over the years I have often quoted Ghandi when looking at Microsoft and their relationship with Free and Open Source Software: “First they ignore you, then they ridicule you, then they fight you, then you win”. FOSS has not “won” yet, but the frontline is moving and it is open source software that is winning.

Apache Wookie passes W3C Widgets conformance

After a marathon code sprint [well done Scott - RG] Apache Wookie (Incubating) now passes all 166 W3C Widgets conformance tests, the third application to reach a 100% pass rate.

Two other applications - the Aplix Web Runtime engine and the BONDI reference implementation for Windows Mobile - have also been able to successfully pass all the conformance tests. Several others are also approaching a full pass rate, as can be seen on the W3C implementation report.

Not only is this good news for Wookie its also good news for W3C, as more successful implementation helps the progress of the specification. Also, open source implementations can also help other developers build interoperable applications by reusing code. I hope in future we’ll be able to make the widget parser in Wookie distributable as a standalone library as well as part of the Wookie widget engine, to help with this process.

Useful links:

• W3C Widgets 1.0: Packaging and Configuration
• Apache Wookie (incubating)
• A good list of resources on W3C widgets development

One question at the end of my session was about the mailing lists. I had explained that it is very important to have a publicly accessible mailing list that anybody can subscribe to and that you should ensure that all communication about the project is on the mailing list. The question was about why you should use mailing lists for this and not forums.
(more…)