Several coding challenges where made and our very own Sander won 2 of them with MuCoMaCo an interesting Google map mash-up of MLA library data. OSS Watch have provided continuing support services to the Apache Wookie (Incubating) project from the University of Bolton. Recently Sander recently organised a Wookie Training day at OSS Watch. This was led by Scott Wilson, Wookie project lead, and Ross, OSS Watch manager. Scott was with us at Dev8D, so it was no surprise that Sander’s winning entry was a Wookie served W3C widget. This enables it to be readily deployed in a range of contexts with little effort.

The other winning entry that OSS Watch had close connections with was Wookie BaLTI. BaLTI is a sample Moodle course by Mark Johnson and Dan Hagon and features the newly developed Twirlymol and CollabMCE widgets. These 2 widgets use the widget loading and collaboration facilities of Wookie to provide a shared 3D interactive view of a molecule model and shared WYSIWYG editing. Several threads came together to make this happen. Those familiar with OSS Watch and open development will not be surprised at how open collaboration has made this possible.

Since we spotted Mark’s announcement of his first small contribution to Moodle and subsequently invited him to present it at an OSS Watch workshop, he has gone from strength to strength. At the Dev8D awards dinner Mark deservedly one ‘Best newcomer’. An award that provided him with a small Lego car kit, which we ‘knocked up’ during the meal, and a rather handmade certificate. The point is that Mark’s enthusiasm for learning about and contributing to open development has been noticed and is sending ripples through the HE and FE communities. Mark attended the previously mentioned OSS Watch Wookie training day, which stood him in good stead for working on the challenge with Dan. Since the Dev8D fun, Mark has pledged on the Wookie lists to reimplement his editing widget without the current LGPL licensed code dependency and to contribute it to the project. Further evidence of Mark’s personal development and it’s far reaching affects comes from his recent blog post. He also supplied us with this comment.

My manager appreciates the opportunities that open development provide to us as a department and an institution, both internally and externally. By letting me go to events like Dev8D even though the things I did there don’t relate directly to my current job, she gave me the opportunity to develop new skills which will allow me to provide new facilities to the staff and students in our institution. We’ve just started an ILT working group with our teaching staff, so hopefully I’ll be able to apply some of my new skills and knowledge to the ideas that come from that.

Mark’s collaborator, Dan, was the first person I met at Dev8D, and as with Mark you can’t help but be affected by his friendly enthusiasm. When I discovered that he had created an interesting Google Wave widget I steered him towards Scott and Mark and watched the magic happen. Scott explain how trivial it was to port the widget to Wookie, and once they’d decided on the LTI challenge Scott added BasicLTI interfaces to Wookie in order to support the challenge work. These are now part of the Wookie project code. More great collaboration followed and someone gave them an Amazon cloud server to install Moodle on. I observed them working together, discussing ideas, fixing bugs and working on their ‘judgement’ presentation. I tried to muscle in on the action with another widget idea but got rather distracted and bogged down in practicalities. Still I do have some new ideas to add to Wookie at some point.

I also attended their pitch to the judges as moral support and I’m glad I did. Chuck Severance of IMS and Sakia and Steve Vickers where in the judging team. A soon as the pitch was over, Chuck and Steve rushed off to add the widget to Sakai, Blackboard and WebCT. Chuck made the point that by using Wookie and LTI it is now possible to have something running in all these platforms, and in a matter of minutes. He then distributed screen shots around various lists.

Dev8D saw many other collaborative ventures seeded or strengthened. New skills were learnt by motivated developers and new contacts made. For example I enjoyed watching Chuck and Tobias Schiebeck work on a tricky Sakai bug. Finally I’d like to mention GNOME who were running an overlapping event in London. After a bit of prodding for collaboration, Willie Walker and Brian Cameron came over and presented on accessibility and GNOME work. Both were very interested in the accessibility possibilities of “Mr gadget” Ben O’Sheen’s demonstration of software to talk to wiimotes. A representative from Dev8D also went over the to GNOME usability hackfest and I expect we will see fruitful cross pollination developing from this mutual interest. Not least is the opportunity for HE/FE developers to learn from a large, established and successful open source project.

Google showed the way, really, with the MapReduce paper in 2004. They published their programming model for processing large amounts of data in parallel and although publishing it, they did not neglect to apply for a patent as well, which was recently granted. Hadoop, which originates from a project at Yahoo!, also implements the MapReduce pattern, but is completely open source being a project of the Apache Software Foundation. And now recently Apache Cassandra has joined the mix. Cassandra originates from Facebook, but has become open source in July 2008. It recently promoted from the Apache Incubator and is now an official top-level Apache project.
Work has been initiated to facilitate integration between Cassandra and Hadoop, which simplified means the Hadoop database HBase is replaced with Cassandra. There has been discussion of this on the list and a feature has recently been implemented. So there’s Yahoo! working on Hadoop and Facebook working on Cassandra, and recently also Twitter has announced that it is working towards using Cassandra for their backend. Also worth mentioning is the open source implementation of Amazon’s Dynamo database which is named Voldemort. This project is used and actively developed by LinkedIn and is therefore another example of how you can benefit from the work this large company is investing by engaging with this project.

To me, this all shows that there will be large investments in NoSQL databases from major companies in the coming years, and it will all be in open source software. This means that there is a lot of opportunity for anybody who has to deal with big data to profit from this investment. All you have to is try out the software and engage with these projects. Researchers also have to cope with more and more data, so I think they have good reason to follow these developments closely and step in to benefit.

Those with little or no experience of implementing computer systems assume these savings come from the fact the free and open source software does not carry a license fee. However, this is not usually the case.

Anyone who has rolled out an software solution, even in a small organisation, will tell you that there are hidden costs. These include training, support,  customisation and maintenance.

In 2005 BECTA published “A study of the spectrum of use and related ICT infrastructure costs” which concluded that training and support costs accounted for 60% of total cost for any software solution. The report also found that open source software reduced these costs by 40-50%.

Further to reducing training and support costs, open source can reduce the cost of customisation for specific environments.

It is extremely rare for a back-office software solution to be a perfect fit for any specific organisation straight out of the box. Consequently, the software needs to be customised to suit specific needs. In a closed source environment there is a single provider, or a limited set of approved providers, who can make these modifications. However, in an open source environment anyone with the appropriate skills can make these modifications, including internal staff.

As a result of this competition, market forces can often result in a lower cost for a tailored product. Just how much can be saved here depends on the customisations you need to make.

Finally, the open source culture of code sharing results in lower development costs for the software in the first instance. That is, once one user has commissioned a specific feature or configuration option the results of that work is available to all. As a result, the more a product is used and developed within any given domain, the more widely the development costs are shared. In addition to a reduction of costs open development can significantly increase the rate of innovation as it brings together great minds to collaborate on shared solutions.

Where there is no pre-existing solution to match ones needs the open developent model can be an extremely cost effective way of reducing cost. This process is examined in more detail in our document “Meritocrats, cluebats and the open development method: an interview with Justin Erenkrantz.”

The documents on our web site undergo a rigorous quality assurance process that ensure they are technically correct and well scribed. The result in this case is an comprehensive introduction to a topic that can be over looked by projects, or may cause confusion and uncertainty.

I have on several occasions heard lead developers say that if they make their code open source they fear they will loose control and anyone can update their source, leading to chaos. As you read these documents you will see that this clearly should not be the case. The project leaders remain in control, in fact they make the decisions on who the leaders are and how the project is controlled. The governance model describes how this happens.

Having a governance model in place is one of the clear marks of an open source project that practices open development. That is, it marks a project that positively encourages community engagement.

Governance models provides an introduction to the what, why and wherefore of managing an open source project.

A governance model describes the roles that project participants can take on and the process for decision making within the project. In addition, it describes the ground rules for participation in the project and the processes for communicating and sharing within the project team and community. It is the governance model that prevents an open source project from descending into chaos. This document explains why a governance model is necessary, considers some of the challenges associated with adopting a governance model in open source projects, and looks at the key areas such a model needs to cover. It also describes how to encapsulate your governance model in a governance document.

Meritocratic governance model provides a detailed insight into this common model that is lead by an elected leadership team or ‘board’. A template is provided for use by projects interested in applying this model.

The meritocratic governance model is a commonly found model in which participants gain influence over a project through the recognition of their contributions. The Apache Software Foundation (ASF) is perhaps the most famous example of a large-scale meritocratic community. The foundation operates with an almost completely ‘flat’ structure, which means that anyone willing to contribute can engage with their projects at any level.

Benevolent dictator governance model describes another popular model where one person leads the project and has a final say in decisions. Again a template is provided for projects wanting to use this model.

A benevolent dictatorship is a project controlled by a single leader. Perhaps the most commonly cited example of the benevolent dictator model is the Linux Kernel project, which is run under the direct decision making leadership of Linus Torvalds. Being a benevolent dictator is not an easy job. It requires diplomacy and community building skills, in-depth technical knowledge of all aspects of the project, and exceptional levels of commitment and dedication. However, as the Linux Kernel project illustrates, it can be very effective.

With any project, good leadership or management are vital, and these documents will help you install the basics with little overhead. If your project already has a governance model in place then these documents could help you refine it, perhaps by making it explicit. If you don’t yet have one, then these document will help you decide what model best suits your style, and quickly get it into operation.

And you can do it all without any sign of pointy hair.

Scott Wilson, the Wookie guru from Bolton University, where it all started, started the day off with a presentation (pdf) of what widgets and Wookie are all about. Widgets are basically small mini applications that are designed to work in a small view area. Many platforms have created their own format for it, but the W3C is working on a set of specifications for it with a consortium of partners from both traditional computing and mobile platforms, which will lead to a true cross-platform standard which will hopefully lead to widespread adoption. A minimal W3C widget consists of nothing more than a config file and an HTML file, zipped up as an archive with file extension .wgt. The config file contains basic configuration such as the name, description and preferred dimensions of the widgets. The widget can furthermore include as much HTML, CSS, images and JavaScript files as one would like.

Apache Wookie (Incubating) is an application that provides a W3C-compliant widget server. You can use Wookie to deploy widgets and you can serve W3C widgets from the Wookie server in third party applications. Plugins have already been written for Moodle, LAMS, Sakai and Google Wave. Wookie also has a REST API that can be used to get, or create widgets.

After Scott’s intro it was time to get dirty. Ross handed out CDs containing the latest sourcecode of Wookie (which can be downloaded by anybody from Subversion) and prerequisites like a JDK and Apache Ant. His presentation (pdf) was about ‘how to build your first widget’. I was surprised to see that there were 10 people with Mac-books in the room, amongst 4 Windows machines and one Linux netbook. Apple surely knows how to impress the developer these days! After some initial troubles with environment settings etc. most people got up-and-running fairly quickly and were ready to build their first widget. Wookie provides handy Ant tasks for building and deploying widgets, which means that generating a hello-world skeleton widget is as easy as typing ant seed-widget and answering some questions about the name, description and dimensions of your widget. After you have started up the Wookie server using ant run you can deploy the widget using ant deploy-widget. That was it, quite easily. I must say, having moved away from Ant and using Maven2 for the last few years, it’s nice to be remembered of the powerful features Ant has to offer. Especially since Wookie uses Ant in combination with Apache Ivy, the dependency management alternative for Maven2. (To be precise, you can also use Ivy with Maven2 repositories). Ross also demonstrated how you can make use of OpenStreetMap JavaScript APIs to embed cool navigational features in your widget quite easily. You can check out his presentation (pdf) or directly check out the source code of the tutorial including the example JavaScript.

In his second presentation (pdf) Scott focussed on some design principles behind the widget specification and gave a walk-through of how you can design a more advanced widget by making use of features of the W3C widget object API and integrate with the Google Wave Gadgets API. No Wave server is needed to get this working, as Wookie can handle everything for you. Scott demonstrated a Task widget with collaboration features, that can be used by different users concurrently using State and Participants.

After the break it was high time for everybody to create their own widget and some interesting ideas had come up. One of us decided it would be much cooler to hack directly in the server code instead of building widgets and he submitted a patch to Wookie to allow hot deployment of a widget to ease the development/deployment cycle. That’s very cool, thanks Matthew!

The rest of us built some widgets for a wide variety of purposes. One of the nice things about the widgets was that we could easily merge them all together on one Wookie instance and show all widgets there. These were some of the widgets that resulted from this 1.5 hour hack-fest:

• Video player embedded in a widget with fallback to other formats depending on the user agent
• Display a list of links using output from one of the Yahoo pipes
• Display the last.fm playlist of a user and show what that user is currently listening to
• Show a canvas drawing where multiple people can collaborate by working on the same drawing using HTML5
• Cool kids’ game where the user can name his pet dinosaur
• Currency converter that (eventually) would use an external currency conversion provider

It was fun to see how easily you can create functional widgets. If you make use of external JavaScript APIs or data feeds it is also quite simple to create a useful (or not so useful…) widget. This was a nice conclusion of the day and seeing all the widgets we had created we thought we had deserved our beer and headed off to the pub. Thanks to Scott and Ross for making this a successful Wookie training day!

Until this fallout from the recent takeover of Sun by Oracle, Willie was employed by Sun to work full-time on GNOME accessibility. The removal of Willie’s salary has removed a critical source of funding for open accessibility and the community is reeling as a result.

However despite the understandable concerns for the future of both Willie personally and GNOME accessibility, this is also a opportunity for both. People like Willie are highly sought after by employers who value leadership skills coupled with excellent technical experience. A couple of people described Willie as the Linus of open accessibility, a simile that has some merit. We can hope his next employer (or funder) will allow him to further develop his passion for accessibility, building on his impressive legacy to date.

For the GNOME and open accessibility communities, the impact of this seemingly crass business decision also causes us to focus hard. It can be a catalyst for improving the sustainability of this small but effective community as Willie himself indicates. I’d like to explore the subject a little in this post.

In general people get involved in open source for selfish reasons. These may be personal needs, corporate motivations or academic interests. The power of open development comes from working together to develop and maintain a common resource that benefits all players. The famous phrase is ’scratching an itch’. When it comes to open accessibility, however, there is an extra dimension. While many members of the community are users of accessibility, others are not and are involved for more complex reasons like social concern, if not quite altruism. This leads to members being in a position of “scratching another person’s itch”. There are elements of accessibility being a basic human right and these colour the community relationships and explain some of the strong outraged reactions to Willie’s layoff. As an aside it’s worth recalling Sun’s significant contribution to accessibility, something that was obviously not core business for them.

The fact that community members are in it for largely selfish reasons means they are likely to leave for equally selfish reasons. There should be no surprise at that. The key is to develop a broadly diverse community that can sustain any individual member’s exit. This is the opportunity I see we now have. I hope that Willie will continue to work full-time but I also hope we will work hard to attract more members who will also bring resource with them. Many of the reactions have vocalised the need to find funding but I feel we should focus on building the community first and the funding will follow. We also need to build community as, to be frank, there is a huge amount of work to be done, as can be seen on the GNOME 3.0 accessibility roadmap.

That might sound rather glib and the question is how can we move forward and encourage? Building community is difficult and not a science but there are many good examples to learn from. I’m fortunate to work for OSS Watch who’s key message is open innovation through community. Ross Gardler our service manager is also Vice President of Community Development at The Apache Software Foundation. The Foundation are also highly experienced in community development. Their informal moto is ‘Community over code’ and most of their activity is community building. For example the Apache Incubator helps projects develop their community and graduation requires at least 3 independent comitters to have joined. So there is a wealth of experience available to tap into and I’d like to see how the open accessibility community can use this to become more sustainable.

On to some practicalities. We are already seeing signs of the community dusting itself down and moving on. Eitan posted yesterday on further plans for the GNOME accessibility ‘hackfest’ at the CSUN accessibility conference. CSUN is THE accessibility conference and this year GNOME joins Mozilla in having a booth. This is the perfect opportunity to introduce GNOME’s work to the #CSUN10 visitors and encourage users and companies to engage. If you are going to CSUN be sure to find the booth and meet the team. The hackfest is the place for other developers to come along and learn what the code looks like and what needs doing. If your are a GNOME, KDE, Linux or Linux Mobile developer you should look us up to find out how to make your program accessible or how to work on accessibility programs.

This year the winners of Projects:Possibility’s SS12 open accessibility coding competition have been invited to attend CSUN. They will look around and present their winning projects. Accordingly computer science students from CSUN, UCLA and UCS will be able to learn about GNOME accessibility and find how they can engage in the action. At a minimum they will take their knowledge of GNOME to their future employers.

In a couple of weeks the GNOME Usability hackfest is in London and overlaps with the Dev8D developers days event. Cross fertilisation is planned and given that accessibility may be viewed to be a part of usability there is another opportunity to explore how to support GNOME accessibility.

OSS Watch have developed a tool that will be useful for exploring the sustainability options for GNOME accessibility. It’s part of our forthcoming Software Sustainability Maturity Model and provides a Q & A on the areas that need to be be covered in order to reach open sustainability. I encourage community members to try it on their project or the community as a whole. It will help focus on the the gaps and provide a common language for discussion of the solution. The form provides detailed explanations and the results are presented as percentages. If you are not sure just leave it as “don’t know”. Results are likely to be cleared at some point, so if you want to keep them drop us a line and we will provide a copy.

So in summary the news of Willie’s layoff is a source of considerable concern for him personally as well as the GNOME accessibility and the wider communities. It is also an opportunity to move on and develop new strengths through open development. The community has previously survived funding loss (IBM) and a key player leaving (Bill Haneman). As Willie says in his email - spread the word far and wide. The time is good as there is not only growing interest in open source in general but also a widening awareness of the benefits of open accessibility. If you are a member of the community then you can start thinking about how to reach out. If you are not yet a member then do introduce yourself at one of the events or on the lists or IRC.

we have a release of Matterhorn now, and people start to use our system and they need support. I’m sure that many of us are willing to help these adopters, but in which way should they communicate with us?

This prompted a discussion I have seen many times, and so I was prompted to post my response here.

In my opinion there are two main reasons why someone would support a user:

1. they are selling services
2. they want to improve the quality of the product

Financial transactions should be divorced from community activity and thus, from a community perspective, we are left with those wanting to improve the project (I’ll return to paid support later though). People providing support in the community have two main objectives:

1. increase the number of users
2. understand the problems users are facing in order to improve the product, to attract more users

Increasing the number of users will ultimately increase the number of contributors (bug reports, feature requests, documentation, user support etc.) and eventually developers (code improvements). Thus attracting users is a key part of creating a successful open source project.

However, not all users will become contributors, and not all contributors will become developers. In fact, the numbers of people progressing along this scale of contribution is very small. Nevertheless, just one contributor is a reduction in the centralised cost of development and thus a step towards sustainability for the project.

For some people the idea of free support for a growing number of users appears to lack scalability. They ask “if we are attracting users at a faster rate than contributors/developers how does the project continue to provide support? Surely there is  a danger of too many resources being devoted to support and not enough on development.”

These are common concerns in a growing project. However, these assumptions ignore the fact that some people are willing to pay for support. The ideal solution is to provide a user support mailing list along with supporting documentation. There is a need to encourage everyone to assist with these community support channels. This channel should become the place where the not only users get support, but also where those providing paid for support seek support themselves. However, support provided from the project community is provided on a voluntary basis and therefore no guarantees of service are provided. The message is clear, if you want guarantees of service then you need to pay for it.

Of course “paying for it” may not mean in cash. For example, if an organisation is known to provided paid for support but they also provide resources for project management, documentation, code or some other contribution they are earning “credits” to get support themselves.

Over time, the number of “first level user support requests”grows. However, the number of people able to answer these questions is also growing, lets not forget that some of those users are still around and are now indebted to the support community. Furthermore, since a healthy project encourages people to contribute early by documenting their experience in FAQs and getting started documentation there is an increasing amount of support documentation for newcomers.

This self-help culture enables core community members to focus on bug reports and feature requests rather than first level support requests.For those users who need a fast turnaround on support requests, they will have to pay. They may contract a third party or they may use local resources to set up a local support infrastructure.

If these paid support providers are smart they will reduce their own costs by interfacing with the wider support community via the project support lists. They will both consume and produce commons support materials in the project. They will also recognise that visibility in the community support channels is a form of marketing for their paid-for services. And this is where the virtuous circle finally closes.

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 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.