I’m going to write a small guide to building open source communities….so, will use this blog as a scratch pad.
First some links of previous stuff:
Those organisations building platforms on top of PubSweet gather together every 3-4 months for our PubSweet Community Meeting. It started off as Coko, Hindawi and eLife but now we are also joined by the wonderful folks from the European Bioinformatics Institute. The events usually go for 2 daCollaborative Knowledge Foundation
Open source software that is to succeed in this new world is going to have to be better than anything else. You can’t sell just openness anymore.Opensource.com
If we want open source UX to improve, we have to change the way we’re approaching the problem. Learn how the itch-to-scratch model works if we’re consistent in how we apply it.Opensource.com
Open source has been amazingly good at solving two sets of issues: 1) infrastructure and 2) developer tools. This is because those developers and users are basically the same people—the developer is an “insider” to the problem, understands it well, and is motivated to solve it.Opensource.com
Oh my gawd….didn’t think there would be so much of my own stuff to re-read first! eeek!
So… it’s been a bit of a year. I was pretty busy looking back. I think I spent about 9 months on the road. I did some surfing. Bought a fridge. Plus some other stuff… so…. looking back….
The year started with a yet-to-be formed PubSweet community. PubSweet is the underlying ‘open infrastructure’ piece of the puzzle that enables folks to build any kind of publishing workflow on top of it. It is used for books, micropubs, content aggregation, journals… a lot. But at the beginning of this year there was one org building on top of it – Coko. Now, we have 9 publishing organisations building on it and 13 or so platforms in play. All that in one year… can you imagine. It is phenomenal growth. The best thing is the feeling in the community is awesome. As Geoff Builder recently said at a Coko meet “I can’t say enough how amazing it is that you aren’t killing each other”… very true.
This kind of growth and goodwill didn’t happen over night. I’ve been involved in many open source projects where there is no noticeable growth at all over many years. In fact, it was by watching these projects and trying and failing myself a number of times that I learned how to make this work. I had a plan from the start and strategised this growth. There are a few key parts… First… the proposition is transparent. It’s a no bullshit kinda thing. You can’t buy your way in, you can only be part of this community if you play nice. You must be upfront and work in good faith. If not, then we don’t want you. So it’s transparent, we require transparency, but it is required. If you aren’t transparent then see you later.
Another critical piece was to develop processes for consensus. We have a number of workgroups that have helped with this. We also have an RFC process and 3 meetings in person a year where more difficult stuff can be meted out. It works very well. It is all also, by design. You must intentionally design such stuff and I spent a lot of time working through these scenarios in my own head. It takes time because each community has its own character. You want to make sure you have the right resonance with your strategies and sometimes I need to ponder this stuff a lot, let it sit and then bring it about. Also necessary is to have leadership. I provide a lot of that but I also strategised very explicitly for Jure to be the central pin for the PubSweet community. He is an awesome leader of the PubSweet clan but also it must be noted that this doesn’t ‘just happen’. Jure and I spent a lot of time talking through these things, working out what sort of tone we needed, how to best enable people to feel they could be part of this while curating it so it’s not a free for all. Jure has really risen to the challenge and IMHO stands as a case study of good community leadership.
Andrew Smeall from Hindawi and Paul Shannon from eLife have been early leaders in this community. To have such goodwill and leadership from folks like Andrew and Paul is really amazing. They have been in boots ‘n all from the beginning and never blinked. They are heart n soul and mainstay keepers of the PubSweet community ‘way’. I feel very privileged to work with them.
Also at the beginning of the year, Editoria was alive but no books were being put through. We have since changed that with at least three scholarly publishers using it in production as well as Book Sprints using it (recently used in a World Wild Life Fund Book Sprint). We got there also by careful strategy. Alison McGonagle-O’Connell has been out there presenting, demo-ing, and explaining Editoria to all comers. Alison is a joy to work with and I admire her can-do immensely. She’s a tough cookie and now the wizard of Editoria. Alison has brought people closer to Editoria which peaked this year with a Editoria community event. We got about 35 people there and I facilitated the process (after designing the event loosely based on the PubSweet events). Critical was a newly designed Feature Proposal process. I had to design it so that publishers with no in house dev resources could ‘take ownership’ of the product and also so that publishers, rather than technicians, could write the proposals. We received 36 proposals in 2 weeks from 6 publishing orgs. Amazing. There is now a 3-month roadmap in play because of this.
xpub-collabra and perhaps micropubs will go through similar process transitions next year.
paged.js is also flourishing. I started the project with Shuttleworth funding in Feb and now it is integrated into Editoria and it has already been used for several books. It is also growing quite quickly as a community, some of this is ‘auto growth’ – growth that just occurs with no assist – and some of it is from the efforts of the paged.js crew – Fred Chasen, Julie Blanc and Julien Taquet. Julien in particular is proving to be a very good community leader in this area. They are an amazing crew doing amazing work. I don’t suffer from FOMO (fear of missing out) but I really regretted not being able to go to the paged.js workshops in Paris and Brussels in November. They looked amazing.
Then there is Wax…. the editor is growing fast. We had to rebuild it because the libs we were using were not supported and slow growing. But Christos knuckled down and got it done.. amazing. It is currently a one person endeavor but watch this space as I have plans for community growth around it next year.
XSweet, the XSLT docx-to-HTML converter is also going great guns. V2.0 with math support out in the next weeks. This more or less completes all the things we need form it and the lib will flick into a maintenance mode.
Then there is Workflow Sprints. The process I designed for helping publishers work though their workflow woes. It takes 1 day per org/workflow and has proven to be extremely effective. I’m now training facilitators to do this as it is proving popular and I can’t do them all next year if it comes down to that. Coko is also able to generate revenue from it which is cool.
Then there are design sessions which I still facilitate for various products including Editoria, xpub-collabra, and micropubs. All interesting projects and the design sessions are fun and sooooo effective. Who said publishers couldn’t design their own solutions? Not me…
Also this year I have been peripheral to the Book Sprints team. I gave up direct involvement when I got my Shuttleworth Fellowship. Thankfully Barbara was there to take the helm and has done an amazing job. We have had a couple of meetings this year and it has been awesome. We broke 1m NZ this year for the first time…amazing. Many people still don’t think it’s a real thing 😉
Also from Book Sprints we get many requests from people who love what we do but want ‘not a Book Sprint’…ie they have some other format/media/context etc they want to think about. So this year I have also founded SprintLabs to act as a bucket to put these experiments in… more on this in the new year.
Also this year I finished my Shuttleworth Fellowship having reached the 3 year maximum and became an alum. That was quite a moment. Strange thing is, I feel more a Shuttleworth Fellow now than I ever have 🙂
Needless to say my journey is unconventional. All this stuff is stuff people told me wasn’t possible. All of it. Book in 5 days, impossible! You can’t use browsers to typeset books! Headless modular publishing CMS – impossible! Publishing platforms are an intractable problem! You guys will never be able to build community, it just won’t work!
Yeah yeah. Fuckem.
And there was a lot of other stuff this year too. But honestly, where do I get the time? Where do I get the time to surf? I have no idea. One of the tricks though that I have learned is to trust the people you delegate stuff to. Create an environment for them to succeed and let them go. For the most part I just need to talk things through with them and help keep them and everything on course. They also have to go with my rather counter-intuitive, emergent, way of problem solving and doing things. If they can’t then it doesn’t work out, if they can then we do great things. Which means, of course, lots of travel is needed and talking to people. I am a great believer in remote teams but I am not a believer in remote-ness. If that makes sense. You gotta be close to people so they can trust you and you trust them when you aren’t there. Its for this reason some of our meetings happen on beaches 🙂
It is what it is. It’s been a huge year.
Still, got to make a surfboard this week and 2 Workflow Sprints to go (in the US)… no matter, I’ll be here in no time…
Recently we took the Editoria product, which is relatively mature now, to a newly designed community process. It was an interesting exercise. We had previously been developing explicitly for the requirements of one organsation – UCP. The task was to now take the product to a community and transfer the mandate of ‘ownership’ to multiple organisations and individuals (‘the community’).
I’d done it before, but this case was significantly different. Most recently I had designed processes that successfully turned PubSweet, the core ‘headless CMS’ from a product developed in isolation (essentially by Coko for Coko) to a community-owned product. I designed a strategy to transfer that mandate and engage a series of early adopters – namely eLife and Hindawi – through a series of events. These events were carefully crafted to communicate that we wanted to embark on a disarmingly frank journey of trust and good faith – to expose an offering, warts and all, to those organisations attending to take collective and collaborative ownership of the product and the vision.
From the outside it might look like we were offering a product – PubSweet. But that is not what we were offering. We were offering trust and goodwill.
These offerings can only be made if there is genuine good faith and a willingness to offer to build trust amongst all parties. This must be communicated by being vulnerable and humble. At the same time, the offering is not without vision – there does need to be a core ‘hook’ that people can rally behind.
So, with PubSweet I designed and facilitated a series of events to do this. The first event was to get the main players onboard, and we are very lucky that Hindawi and eLife were all in, which is a reflection on their own ability to work in good faith and trust.
The following events were curated to cement a culture where collaboration by virtue of trust and good faith was shaped. I designed processes for transparent collaboration, and before long, these processes became part of the culture of the PubSweet community. It works now very beautifully. We can always improve things but we have instantiated a very successful and productive collaborative culture and it is a very healthy community. So much so that it is, to some degree, now self-replicating. When EBI joined the community much later, they were inducted into an existing culture and expectations were clearly articulated by the community in how they acted. That is what a healthy community culture is all about, and to be sure, it doesn’t happen accidentally, it is intentionally designed and purposefully facilitated. When it works (to a degree) it maintains itself (after a while).
So, when it came to Editoria, I needed to come up with a similar strategy. Except that in this case, the stakeholders were not builders. None of those interested in Editoria had developer or designer folks in their team that could commit to contributing to the development of the product. This is entirely unlike the PubSweet community which consists entirely of orgs with their own dev teams.
So, the context was quite different. How then do you hand over the ownership of a product to a community that cannot itself change that product? What is there to own? What is there to collaborate on? Where is the shared interest?
For this reason I curated the Editoria meeting to articulate our desire to transfer the mandate to the community. It was also done with a sense of vulnerability and humility. I designed a flow during the meet to lead up to handing over the ownership of the product to the community, the pivotal moment being a Feature Proposal process which I communicated near the end of event. The Feature Proposal process enabled anyone (org or individual) to propose new features and changes to Editoria. These would then be filtered through a transparent selection process and the selected features would be built. In this way now the community can affect the product. They literally effect its development path. They can change it, they have a shared interest in the development of the product and a reason to collaborate.
In the two weeks following, we had 36 Feature Proposals made by 5 different publishing organisations. That is amazing. These were not insignificant proposals and also there was a lot of discussion within the newly formed community about the relative merits of each, what could be improved, who thumbs-upped the ideas etc…
Again, this process didn’t happen accidentally. It was intentionally designed and purposefully facilitated. It is an example of what I mean by intentionally designing communities. Part strategy, part emotional labor. Always risky but extremely satisfying when it works.
It is also work that never ends.
So, I’ve been building communities for a long time. My first job (real job) was managing a radio station in the city of Hamilton in NZ. It was the independent student station Contact 89FM and it was the center of the city’s music scene… at least the center of the cities good music scene…the station was a thriving central hub. We supported the local musos with free ads, live-to -ir performances, battles of the bands (more fun than the name suggests), booking support slots for them with national and international acts coming through, played their music on-air, had a dedicated show for the local stuff; and while I was managing the station, we even built a recording studio, a record label and a tv station to support the local scene…
I never thought about it as community building back then but it is exactly what it was… After that, I did some other stuff before becoming a professional artist some years later and that was also all about community. Except this time I was really ‘in’ the community. The community was a wonderful assortment of crazies that did wonderful art (sound art, digital art, network art etc) that had independent practices and wandered around the globe going from gig to gig… it was an incredible time… I looked forward to seeing some collection of my buddies in maybe Linz (Austria) for a exhibition, or Helsinki for workshops or maybe for the start of a conference on a boat, or a conference on the transiberian express, perhaps at a shared workspace (the thing) in New York, or, as it happens, on an icebreaker on its way to Antarctica. It was an incredible time and I was very lucky. I feel lucky to this day to have been part of that. It was a privilege and it also gave me a sense of what it is like to be inside the community bubble…
Then I started FLOSS Manuals, which still goes to this day – a community writing free manuals about free software. This was an online community. I had to build that up from the bottom. It was hard work, but it worked… I learned a lot about how to build momentum, stone by stone, with a group of people dispersed around the globe that might never meet each other…
And now, Coko, which is also a community. In fact, it’s a community of communities – a multifaceted community of folks that have similar but disparate needs. Journals, books, micropubs etc only have so much in common, but they also have so much in common… its a difficult juggle keeping them all going and feeding the right ‘community building nutrient’ to the right community…
So… as I fly over the Equator, on my way to Morocco for a week from NZ (I see I am over the Banda Sea) I am pondering… what have I learned about community? It must be something after all as I’m pretty sure I know what I’m doing. But the knowing feels very ephemeral… like most things I do, I don’t realise how much I know about it until I tell someone else… so, here goes…a short telling to see if I can distill some latent knowledge into this post…
Off the top of my head, going rogue with the keyboard… community is something you can build, but the building is a weird process. You must be simultaneously inside and outside the community. Inside, so you can speak with the other community members in a way that is genuinely of the ‘I’m with you’ variety. It is a kinship you need to maintain and it can be nothing other than natural. If it is not natural, then you are essentially an ‘outsider’ and outsiders are not, by definition, part of the community. It is ‘insiderness’ you need to achieve.
But… at the same time, you must be a strategist. You must know how to massage community to maintain, and build, momentum. You must be able to act deliberately to bring about the growth of the community. This requires constant gardening as you can not (at least I don’t think I’ve seen anyone do this) lay out the path and then run the community automatically through its paces. You must tend to it and react with it, let it have its own head, but also help ‘keep its head’. In other words, it is constant emotional labor. It is also messy.
Strategising community building also has the danger of ‘otherness’ or ‘outsiderness’. You must never, for example, instrumentalise community. You can not use the community and manipulate it to your own ends. You will just kill it if you do so, or you will reduce your cultural currency, the only thing you really have, to zero – rendering yourself ineffective.
The fuel of the community is essentially value. Communities form around things they value and the more you grow the value, the more the community grows, and vice versa. It is symbiotic. If you want to build a community you must build value for the community. You must also not act out of a desire to build value only for yourself. This is the same as instrumentalising community and it is a shallow act. You, as the community builder, must push value out to the community. The community members must benefit from their involvement. The more you push to them, the healthier the community will be.
The more you contribute to growing that value, the more cultural currency you have. And cultural currency is everything. You can only be given so much by association, the rest you have to earn. Earning it is, like the building of community, and ongoing and constant process. You get as much as you put in. It is not the same as ‘meritocracy’ which is often thrown about by the open source community as a kind of ‘community value metric’. Cultural currency is earned not just by what you contribute but by how you contribute it. The merit of the contribution is only one axis. The other is your ability to make the contribution generously and in good faith. Which is why meritocracy is an unhealthy exercise. How you are is as important as what you give.
Lastly, community is self-associating, self-identifying. You don’t get to ‘appoint’ community. Participants must identify themselves as part of the community.
These are some of the basic mechanics. I am sure there are many more… but I think maybe also not. The thing about community is that it can take many forms. Communities of people making publishing platforms… communities of musicians…communities of book writers… it doesn’t matter…they have the same underlying mechanics… but how you employ your skills to build the community changes dramatically according to the context. You are using the same navigational principles but in substantially different waters with each case.
But, as a takeaway, from this shortish flight, if you want some bullet points I’ll leave these here for now for us both to ponder…
- you are inside the community, it is not ‘out there’
- to build community, you must also maintain something of an ‘external’ position while also being wholly inside the community
- your goal is to build value for the community members
- you must do so generously and in good faith
- you must *never* instrumentalise a community
- community is self-identifying
It’s tricky stuff, but incredibly satisfying when it works.
Was a cool day. We went through introductions, then the workflows of UCP and Book Sprints using Editoria, then we did a deep dive in small groups – each moving through 20 minute demo/discussions on XSweet, Editoria, Wax and Paged.js. Then we talked about features in Editoria that could help publishers which translated into feature proposals, and then finally we had a discussion about what was going to be next for the community.
Enthusiasm and engagement was very high. Awesome.
Comment on this if you are interested in it!
At the moment things are happening thick and fast at Coko, its hard to keep up! Anyways… this just in:
Direct link to sign up here :