Differences between revisions 26 and 27
Revision 26 as of 2012-03-12 10:32:06
Size: 12600
Comment: more flesh to 2nd video
Revision 27 as of 2013-04-15 13:56:24
Size: 12600
Editor: localhost
Comment: converted to 1.6 markup
No differences found!

Intro

Open source communities have developed in time a body of practice about effective online collaboration and project sustainability through the harnessing and managing of work by contributors attracted to the project in various capacities. Some of these lessons can be successfully applied in the context of academic project collaboration. This document highlights some of these lessons and illustrates them with fragments of videos from OSS Watch interviews with open source leaders.

Online collaboration

The development of the internet has created unprecedented opportunities for our natural inclination to work together, as we are now able to collaborate effectively unconditioned by space and time. Open source communities have developed efficient ways of coping with the challenges of online collaboration by streamlining these processes and making them resonate with one of our most basic instincts of building communities.

In this newly emerging online collaboration context, the tendency is to shift from a so-called 'culture of approval' to a 'culture of moderation'. In a 'culture of approval' official membership and hierarchical approval are absolute prerequisites to one's ability to propose changes to an existing system. By contrast, in a 'culture of moderation' everyone is encouraged to openly contribute under the watchful eyes of the community, in the comfort that the proposed changes can easily be reverted back if inappropriate.

This freedom to collaborate online must be preserved and should not be taken for granted

Universities had been early pioneers of online sharing, and after decades of trying to control and exploit academic collaboration are now moving towards their original position

Making an effort to get out of one's skin, e.g. by collaborating with business partners, is key for maximising the innovation potential of this sharing

Building community

Community building is hard work but is essential for creating innovative and sustainable products

One of the most difficult tasks is attracting new contributors, e.g. by offering them rewarding ways into the community

Providing clear indication of how contributions should be made is essential for community building

All types of contributions should be encouraged, both technical and non-technical

Like in a football team, projects needs to know their members' strengths and weaknesses and deploy them accordingly

Knowing one's Governance provides structure and explains what roles exist and how people can contribute effectively

A set of tools providing quick feedback loop is essential for online collaboration

The feedback loop between users and developers can sometimes be affected by cultural and linguistic barriers

The tools used for communication should be open. At project level, this creates a sense of sharing and maintains awareness of what various groups do across the project. Beyond the project team, open mailing lists allow outsiders to sample the internal dynamics of the project and to understand what are the various people's roles in the project

Alternative economics

People don't just work for free; their motivations for contributing to open source projects are ultimately of a personal economic nature, even if this is less obvious in the first place

People get involved in open source projects because the overall benefits they get outweigh their contribution efforts

Conclusion

  • Work in the open, iteratively, collectively, confident that any mistakes can be reverted and the rough versions will be polished by the community
  • Building community is hard work, but needs to be done for sustainability reasons
  • One hangs around as long as the overall benefits outweigh contribution efforts


Jim Jagielski, Apache Software Foundation (now at Red Hat)

Community over code (2min 33sec)

The ASF community believes that by putting effort in creating healthy, long-term sustaining communities you get good quality sustainable software. This is not the only way of developing open source software; others adopt other approaches that work very well for them. However over the past 10 years the "ASF way" has shown itself to be an efficient way of developing open source software, with key technology projects like Java and XML growing by using this approach.

Meritocracy (5min 14sec)

The meritocracy concept is based on the assumption that those who have made valuable contributions in the past are likely to continue in the same way if they are given the ability and responsibility to do more. There are levels of engagement with the software we produce, from merely users, to people able to report bugs, to those who provide patches, to those given commit rights, to those adopted as PMC members.


Gianugo Rabellino, Sourcesense (now at Microsoft)

Open source lessons for online collaboration (3min 26sec)

Open source was a pioneer in building and managing distributed communities. These days we collaborate online more than we did 10 years ago, and this tendency will increase in the future. Therefore the lessons learned from open source will become even more relevant. We also see a paradigm shift in online collaboration, from a 'culture of approval' to a 'culture of moderation'. This means that online communities realise that it's more efficient if people just do stuff under the watchful eyes of their peers, knowing that the changes they implement can be easily reverted if necessary.

Come for code, stay for community (2min 24 sec)

My first contribution to an ASF project came from entirely selfish reasons: I simply realized that I can take some open source code and adapt it to my company's needs. I then saw that it's easier for us to contribute our version back than to patch it on every new release. But from this stage I then moved to the understanding that by contributing back I was also getting a much better software, my company was getting more business, I was learning new stuff and meeting exceptionally gifted people. So the initial bait is technical, but you end up staying for the community dynamics.


Stormy Peters, Gnome Foundation (now at Mozilla)

Attracting new contributors (1min 24sec)

The hardest part in building a community is finding new members and encouraging them to contribute. People often underestimate how difficult it is for new members to find their way into the community and get the courage to make their first contribution. Communities need to make an effort to provide encouragement, refrain from harsh criticism, provide newcomers with information about how they can contribute. One way we do this in Gnome is by offering newcomers the opportunity to work on 'love bugs', i.e. easy to fix issues that give newcomers a reasonably easy and meaningful way into the community.

Open mailing lists (2min 05sec)

Mailing lists are the main communication channels in open source communities. People in a project may also be in touch via IRC or other means, but all key discussions are held and recorded on public mailing lists. It's not uncommon for project members to check back discussions held a few years back, or for newcomers to look for the past activity of the people who provide them guidance. In addition, anyone can subscribe to these lists, both from outside Gnome and from different Gnome teams, therefore you never know who is on these lists. It's as if you had open team meeting rooms.


Noirin Shirley, ASF Board (now at Google)

Non-code contribution (3min 12sec)

Writing code is only one way of contributing to an open source project. In ASF projects other types of contribution, such as writing documentation and event organisation, are equally valued. In fact, in a world of software developers and engineers such rare skills, that can considerably boost the success of your project, are perceived as even more important

Meritocracy (4min 35sec)

In an ASF context, meritocracy is 'do-ocracy' combined with a step-by-step progression path in two stages (committer and PMC member). Each of these stages rewards one's merit accumulated by doing things with extra opportunities to influence the progression of the project


Roland Harwood, 100% Open

Business and academia need to collaborate more (3min 20 sec)

There is not enough collaboration between business and academia, there is a danger that the two sectors become isolated and irrelevant to each other. In other cultures, like France, this gap seems narrower, as experts are expected to be able to use non-specialist jargon and engage in public debates. Specialists in both industry and academia need more exposure to alternative perspectives. Being able to say 'I don't know' can be hugely liberating, as this is a first step in making us more open to other people's ideas.

Encouraging external collaboration can result in unexpected partnership (4min 29sec)

In this example from Roland's keynote at TransferSummit 2010 an open innovation agency helped a Formula 1 car company and an air traffic control service to collaborate on a piece of software that created a multi-billion dollar market


Samuel Klein, Wikimedia Foundation

Universities as natural open innovation promotors (1min)

After a period when universities focused on getting funding by creating proprietary systems to educate the world, they have started to look back at their original role of using the web to allow free access to knowledge to everyone

User/developer communities (2min)

In projects whose main audience are not developers (such as 'One laptop per child') you don't have the same natural feedback loop as in projects where developers build tools for their own benefit. This, combined with linguistic differences between developer and user groups, can create significant barriers to building a vibrant community.


Gerv Markham, Mozilla

Openness of the web (2min)

Openness of the web is essential and should not be taken for granted, Mozilla has been and will continue to be there to ensure it stays open


Steve Walli, Outercourve Foundation

Online collaboration (2min 44sec)

The development of the internet has taken our natural tendency of working together to unprecedented levels, as we are now able to collaborate online independently of space and time. Open source communities have developed in recent years efficient ways of coping with this challenge

Specify contribution process (1min 39sec)

Providing clear indication of how contributions should be made is essential for community building

People don't work for free (1min 32sec)

People don't just work for free; their motivations for contributing to open source projects are ultimately of a personal economic nature, even if this is less obvious in the first place


Bertrand Delacretaz, Day Software

Quick and direct feedback (3min 20sec)

A set of tools providing a quick feedback loop is essential for online collaboration (commit messages, mailing lists, issue tracker, automated builds)

Effective team (2min)

Like in a football team, projects needs to know their members' strengths and weaknesses and deploy them accordingly

OSSWatchWiki: OpenApproachVideo (last edited 2013-04-15 13:56:24 by localhost)

Creative Commons License
The content of this wiki is licensed under the Creative Commons Attribution-ShareAlike 2.0 England & Wales Licence.

OSS Watch is funded by the Joint Information Systems Committee (JISC) and is situated within the Research Technologies Service (RTS) of the University of Oxford.