Contents
1. May 2010
1.1. Theme
Title: Community Management Tips
Community management is not easy - otherwise every project would have a vibrant community of contributers. It's hard to get a community together and keep it going. In this podcast we'll discuss some ideas for what works and what does not and some useful resources.
1.2. Discussion Points
- setting the scene - why and why hard?
- lowering barriers: - tools, processes
- Attracting and keeping people
- community management 101
- do you need a official manager
- user vs devs?
- encouraging contribs
- a recent experience
- bike-shedding
- Need some feedback
- know your lurkers
- bike-shedding
- resources - Fogel + Bacon
1.3. Resources
This section includes links to resources that we used to research this podcast.
http://www.oss-watch.ac.uk/resources/researchinfrastructure-community.xml
http://www.oss-watch.ac.uk/resources/howtobuildcommunity.xml
http://www.oss-watch.ac.uk/events/2008-10-20/community_building_reading.xml
http://www.oss-watch.ac.uk/resources/review-producingoss.xml
2. April 2010
2.1. Theme
Title: Project Governance
Establishing a governance model for your project is, according to many, critical to its open source success. We often hear people say that ‘It’s too early’ to formally describe your project’s governance at project start up but that is actually the perfect time to draw up a governance model. Detailing responsibilities and describing how decisions are made does not lead to a situation where a project team loses control, quite the opposite, it enables the project team to clearly set out the way in which the project will operate. It also helps to develop an engaged and open community where everyone knows what is going on and potential contributors know exactly what to expect.
In this podcast we'll discuss:
- a GM is a way of structuring and fostering participation in an oss project
- people need GMs because this enhances their sense of belonging to something they can influence
- meritocracy is key - demonstrate you are trustworthy and you will be given opportunities to do what you want to do
- without a GM there isn't really open development (even if claimed to be open source)
- a GM should contain: vision, member roles, ways to move from one role to another, ways to bring new people in
2.2. Discussion Points
2.2.1. What is a Governance Model?
"If you want to do something and you have demonstrated to the community that you are trustworthy and you have this merit then we will try and give you the environment to let you do the things you want to do".'" - Meritocrats Justin Erenkrantz on the ASF support of meritocracies
2.2.2. Why do we need a governance model?
"I am not going to collaborate on something that I don't feel any sense of belonging to… There is no open development if I cannot influence and have my say in what we do and what we are trying to build. That is not open development, that is free labour!" - Gianugo Rabellino on why a lack of a governance model may limit the payback from open sourcing your code
2.2.3. Is it open source if it doesn't have a governance model?
"To me open development really is what open source [has always] been. So, open source was intended as a development methodology, as a way to build artefacts, which happen to be software, in a collaborative way which is based on transparency, on meritocracy and on neutrality [over ownership] and you need all of them" - Gianugo Rabelino on open development as a key part of open source.
"You are really starting to see perhaps not a split but kind of two camps: you have the open source but on the other hand you have the open development." Justin Erenkrantz reiterates that open source does not necessarily mean open development
2.2.4. What should be in a governance model?
- Project organisational structure
- Roles
- Processes and channels
- Communication
- Bugs
- Contributions
- Submission
- Releases
- Decisions
2.2.5. Next steps
2.3. Resources
This section includes links to resources that we used to research this podcast.
3. Production Process
Where T indicates the publication date of the podcast (the second Monday of the month):
- Show notes (T - 28)
- Define theme and working title
- Collate initial resources
- Define 3-6 key questions
- Bullet point answers
- 1-3 quotes about the topic
- Pre-Production (T - 21)
- Define roles (Newbie and expert)
- Review materials in show notes
- Recording (T - 14)
- 20 minutes chatting over wine
- 10-20 minutes recording podcast
- Editing (T - 7)
- Mark audio with labels for start of topic, interesting quote and beeps (T - 10)
- Remove "errs" and "beeps" etc.
- Post production (T - 3)
- record introduction
- add introduction to edited podcast
- add standard intro/outro
- write RSS entry (including show notes)
- Publish
- Blog post
- News item
4. About
Our podcast will be:
- 10-15 minutes
- chat format
- once per month
- one theme per session as defined by the most recent newsletter
I imagine we'd do something like 15-25 minutes then edit it down.
The goal of the OSS Watch podcast series is to:
- increase visibility of our content and themes
- broaden the visible members of OSS Watch
- have a laugh

