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.

After about half an hour of navigation we entered … an underground parking, and started to doubt that we are actually on the right track.

However we suddenly emerged in a garden on top of the building

We got closer to the place the gps indicated and started searching.

A few people eating their sandwiches watched us suspiciously, while others continued their lunchtime routine.

Finally Bertrand found the magic container.

He filed in the log that documents the history of the find, then took one object from the container and replaced it with one Ross had collected from another geocaching. Anjana volunteered to use the Oakland item in a geocaching she would do in the UK.

In theory there is a slim chance that one of us will come across this object again in ten or twenty years, in a totally different location. I leave those willing to do the maths to calculate how big these chances really are.

A wonderful session Ross, well done.

Message posted today on our social mailing list at work:

Do you lendaround ? Let me know if you sign up and I’ll email you an invite which’ll make it easier for you to connect into the network.

According to their website, Lendaround is a free web tool that aims to help people borrow things from one another. It’s good to bring friends, neighbours, families and colleagues together by swapping things, such as DVDs, isn’t it?

Why do such tools exist? Apparently, because somebody had an idea that made them sleepless in the first instance, and this person persuaded others to help make it happen:

Looking around his home, Tim noticed how much stuff we all seem to have that doesn’t get used very much — at a time when there are a billion people in the world who have not very much at all, and when it would be good to use a bit less of the earth’s resources.

The email message reminded me of a good read about The Myth of Crowdsourcing my colleague Amir pointed to me recently:

In the popular press, and in the minds of millions of people, the word crowdsourcing has created an illusion that there is a crowd that solves problems better than individuals. For the past 10 years, the buzz around open source has created a similar false impression. The notion of crowds creating solutions appeals to our desire to believe that working together we can do anything, but in terms of innovation it is just ridiculous.

The crowds by themselves, the author suggests, are unable to produce innovation. It is the highly skilled, highly motivated ‘virtuosos’ who are the real engines behind the often misused term crowdsourcing.

Open-source developers are often mentioned as a crowd of motivated programmers ready to meet the world’s software needs. A lot of wishful thinkers love to put forth the notion that all large software companies should be quaking in their boots because a crowd of open-source developers is ready to eat their lunch and create software for any purpose. There is no crowd of open-source developers ready to attack every problem. In fact, most open-source projects are the product of one obsessed individual who wrote the software to meet his own needs. Often this individual was joined by other programmers who shared the founder’s vision and, under his direction, created great software. Yes, there are large teams of developers on open-source projects, but without the virtuoso contribution at the outset, they would achieve nothing.

In OSS Watch consultations with HE projects we often need to correct the general view that open source is mainly the affair of a bunch of bearded geeks animated by common idealistic views. In fact, as mentioned in one of our workshop reports, the open development model that lays at the foundation of most open source commercial businesses is based on what Harvard Internet lawyer Yochai Benkler termed “commons-based peer-production”, a process by which everyone who contributes also gets something back that furthers their interests.

A certain level of pragmatism associated with the business of open source is perhaps not unrelated with the idea of the highly skilled ‘virtuosos’ that make crowds vibrate. Something worth exploring further, maybe in a break between watching two lendaround DVDs.

Keeping a low barrier to entry for external contributors is particularly important in an open source project. New developers might emerge from the project’s user base, but may also come from elsewhere, drawn in by the technical challenge, kudos, or opportunity to improve or publicize their programming skills.

Often the amount of disruption generated by these developers contributing ‘from the wild’ is feared by projects with little practice in open source development.

Karl Fogel writes in Producing Open Source Software:

Opening up means arranging the code to be comprehensible to complete strangers, setting up a development web site and email lists, and often writing documentation for the first time. All this is a lot of work. And of course, if any interested developers do show up, there is the added burden of answering their questions for a while before seeing any benefit from their presence.

Moreover, once new contributors have been attracted to the project, they have to be given as many reasons to stay on a possible. Ensuring that their contribution is valued and rewarded is important to their successful integration in the community, and crucial to maximising the project’s sustainability. As mentioned in an OSS Watch community building document:

Developers will only remain if their leader can make the project a place they want to keep coming back to. This means rewarding hard work by giving credit where it is due and, for those who want it, responsibility for more significant pieces of work.

David Neary pointed in an earlier Gnome blog post at a number of interesting governance success stories from online communities including Blender, Inkscape, Drizzle, Subversion and Maemo. A recurring point in these stories was the issue of making the community grow by smoothing the entry path to new contributors.

In one of these governance stories an external contributor submits a software patch to Inkscape, an open source SVG graphics editor. The commiters responsible with that feature check the code and license and accept the patch. Bryce Harrington, the Inkscape developer who tells the story, goes on:

Following our policy to “Patch first, ask questions later”, we integrated the new feature as soon as practical, without wasting time arguing about it on a mailing list. We figure that the best way to evaluate an idea is to code it up and see how it works in practice. A working feature now is better than a perfect implementation that still isn’t done.

And further down:

… maintaining a low barrier to entry for new developers is vital; we don’t want anyone to give up on contributing out of fear their contributions won’t be accepted.

A noteworthy document in this respect is David Neary’s check list of community barriers to entry. Online communities, David writes, fail to reach a critical mass because potential new members trying to engage with the project encounter some form of difficulty that takes too much effort from their part to overcome. One of the main tasks of the community manager is to identify and iron out these hurdles as much and as early as possible.

A new contributor is likely to encounter three types of obstacles, David thinks: 1. Technical (related to product architecture, programming language, tools, documentation, website); 2. Social (related to project infrastructure, governance model, behavioural norms in the community, relationship between employees and community, transparency of community processes, corporate hierarchy, product plans, management of confidentiality); and 3. Legal (related to licensing issues trademarks, patents).

I personally am of the opinion that it is the social barriers, rather than the technical ones, as David believes, that are the most significant and the most critical to resolve. Nevertheless, his check list largely resonates with OSS Watch’s view about the importance of encouraging external participation for the sustainability of the project, as mentioned in this governance model document:

Since it is not possible for a project to be all things to all people, the goal of a sustainable project is to be as complete a solution as it can be for its core stakeholders, whilst still being of interest to other interested parties. The project must be ready to accept input from unexpected quarters, and must be able, wherever possible, to accommodate their needs. Doing so significantly increases the pool of resources the project can draw upon in its quest for sustainability.

To further address these crucial aspects of community building OSS Watch is organizing a workshop on “Engaging developers with open source projects” on 9 October in Oxford, where open source developers who have been directly involved in HE academic projects will talk about their experiences. We hope to see some of you there.

The first chapter introduces the main themes of the book - collaboration, belonging, trust, social capital, communication - and this is done in an engaging combination of theoretical vignettes and personal accounts drawing on the author’s early experiments with open source. There are a couple of extremely well made points in this chapter, but in particular the importance of fostering a sense of belonging in the process of building an online community grabbed my attention.

Writes Jono:

In the same way that we judge a strong financial economy by prosperity, wealth, and a quality standard of living, belonging is the reward of a strong social economy. An economy is a set of shared concepts and processes that grow and change in an effort to generate a form of capital. In a financial economy, participants put goods and services on the market to generate financial capital. The processes and techniques they use include measuring sales, strategic marketing, enabling ease of access, and so forth. A social economy is the same thing—but we are the product, and the capital is respect and trust. The processes and techniques here are different—open communications mediums, easy access to tools, etc. — but the basic principles are the same.

Building social capital by welcoming new members and helping them develop a sense of being part of the community is a crucial aspect of making it sustainable. This was the subject of an OSS Watch Community and Open Source Development Workshop last year, and Ross alluded to it in an earlier post on software sustainability:

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 multiple financial pots and thus reduces centralized risk. We recognize 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 by enough practitioners to make it viable.

I’m looking forward to reading the rest of Jono’s book. I’m particularly keen to see if he has anything to say about matching personal and institutional drivers in making the cultural change associated with adopting open source effective.

Sadly I wasn’t able to attend the Oxford barcamp this weekend, but looking at the first online reactions it seems this was a great success. About 50 people attended, traveling from as far as Glasgow, with a few representatives from Italy and the west coast of the US.

As Ross mentioned earlier, the aim of this event co-organized by OSS Watch was to provide an opportunity for developers, academics, members of the Apache Software Foundation, IT students and other people involved in the computing and  technology fields to meet informally and find out about their open source related projects.

According to the schedule as of 1pm on Sunday, the topics for discussion included ‘agile management and open source’, ‘aggregating university content on  iTunes’, ‘open ID, ‘the Apache way’, ‘cyberactivism’, ‘open font libraries’, and ‘emotional intelligence as management style’. The participants also had a chance to admire Oxford’s famous ‘dreaming spires’ featured on the barcamp’s cool mugs, and apparently there was even time for a few gigs.

While we wait for a proper assessment of the event, first impressions have already been published by Marcus Povey, Ben Werdmuller and Sylwia Presley. Andrew Luke wrote about the discrete branding of the event and commented on a few sessions on Mapping CCTV and transparency, Cyberactivism, Geomaps and data, Wikis and collaboration and Facebook. Aidan Skinner posted his love notes to Open ID in the barcamp wiki.

I think I would have particularly enjoyed the open and agile development session led by Marco Abis and Gianugo Rabellino from Sourcesense. In his post on the session Marco mentioned the 12 principles behind the Agile Manifesto and suggested that a key term to consider when comparing agile and open development is the customer, referred to in the very first Agile principle.

[…] one of the reasons why it’s so hard to adopt Agile fully - whatever that means - in a typical Open Source project can be nailed down to one single word in the first principle:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

As there isn’t necessarily a customer in the common sense of the term. It might be a whole community, the single developers working on the project or something else entirely.

Apparently a conversation on this topic has started on the barcamp’s twitter channel, and Ross mentioned that a number of UK academics and industry folk agreed to collaborate on a document comparing the Agile principles to the (as yet undefined) principles of open development.

This year the conference organizers are introducing new facilities to assist participants with setting up f2f meetings.  Once registered, check up the Day Planner service. Feel free to use this opportunity to arrange meetings with us on our stand or in the dedicated networking space.

Looking forward to seeing you in Edinburgh.

OSS Watch would like to congratulate Josie Fraser and Simon Mather, two of the contenders for the Learning Technologist of the Year Award. Both have presented at OSS Watch workshops earlier this year. Emerge’s Josie Fraser spoke at one of the five expert workshops OSS Watch organized in July. Simon Mather, Head of Software Engineering for UFI learndirect, contributed to our Risk Management in Procuring Open Source Software event. Simon will also present at OSS Watch’s forthcoming Community Building and Open Source Development workshop on 20 October in Oxford.