Category: PubSweet

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.