Archive for the 'Community' Category

GNOME accessibility - the future

Published by stevelee on February 11, 2010 in Development, Software and Community. 1 Comment

The layoff of Willie Walker by Oracle is causing consternation in the the open source accessibility world, and for good reasons. As lead of GNOME accessibility and head developer of the Orca screen reader for the blind, Willie is a key member of GNOME accessibility. GNOME itself is a key player in the open accessibility field. The recent OSS Watch briefing note on open accessibility identified the importance of GNOME’s position and it’s contribution under the leadership of Willie.

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.

The virtuous circle model of support for open source

Published by Ross Gardler on February 10, 2010 in Development, Strategy and Policy and Community. 1 Comment

On the OpenCast Matterhorn developer list the following question was recently posted by Rudiger Rolf:

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.

Symbian looks serious about community

Published by Gabriel Hanganu on February 5, 2010 in Community. 0 Comments

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.

The power of community put into practice

Published by Sander van der Waal on January 26, 2010 in Development and Community. 1 Comment

At OSS Watch, we actively promote that there is more to open source software than just a licence. Open source projects should use not just an OSI-approved licence but practice the open development method and if they want to become sustainable they should be building a community around their project. Once in a while, we come across a nice example of how the power of the community can be beneficial, and recently one of these examples occurred.

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.

Control versus community

Published by Elizabeth Tatham on January 23, 2010 in Community. 1 Comment

Running an open source project without a governance model is like building a house without plans: a recipe for disaster. A governance model describes how a project is managed and how third parties can interact with that project. In particular, it describes how decisions are made within the project, the ground rules for participation in the project and the processes for communicating and sharing within the project team and the community.

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?