Month: September 2019

More Book Sprints News

From today..

Dog food bonanza

In software dev ‘dog fooding’ is about using the tools/processes/methods you are advocating or building. For example, when I write a book I do it in Editoria, the book production platform the Coko community is building.

So… several times recently I have been in, what seems like, infinite recursive dog fooding…and here is another example… this book:

https://www.amazon.com/dp/1694497119

It was written in a Book Sprint, which is a method I came up with, and I was a participant. It also used Editoria as the tool, which I am part of creating. Finally, the subject is about the Shuttleworth Foundation fellowship, of which I am a fellow… so…there is kind of one big recursive dog fooding going on for me…

anyways… the book is awesome. Its about that rather special org…the Shuttleworth Foundation – and their rather special approach to changing the world. I love them and have benefited more than I can actually know from being part of it. LOVE the Shuttleworth Foundation, but more importantly the people who made it so… most notably Helen King, Karien Bezuidenhout (on Cokos board of advisors), Jason Hudson and Gunner. These are the folks, IMHO, that have been there from one or more beginnings and made it what it is. That such things like this happen, should not be surprising, that they do happen is incredibly surprising.

Check the book out. Its awesome.

Community vs Services

So, pondering further about services… there are two fundamental issues with an open source product offering services as a revenue generation mechanism for sustainability and if the project considers itself a community. They are not insurmountable but if you are going to go down that path you need to acknowledge these issues and think carefully about them.

Firstly, maybe i say something about the community aspect. Many consider open source to be a synonym for community. Infact, thats not the case. Many OS projects are open source in license only. You can use the product but there has been no intentional design to include ‘others’ outside of the initial team/solo lead.  I say here also intentional design because if you want community I believe you have to design for it. You have to design the tone of your project, the pathways in, the processes etc – in other words, you have to design the projects culture. If you don’t do that the history of open source shows that you will probably end up with either:

  • no community, or (potentially worse)
  • a community you don’t want

The second item is interesting because it explains a lot about the lack of diversity in open source. If you don’t intentionally design your community, its probably going to look exactly like you or (even more probable) a worse version of yourself on a bad day. If you want me to unpack that the price is one (good) margarita.

So… lets say you do want a community, and you are setting about intentionally designing for it. So… at the same time, or at least at some point along the same path, you decide you need to start thinking about how to make this growing ‘thingy’ pay for itself. One idea you have is services…

The tricky thing about services, is that as you build up a community an ecology of ‘stuff’ will start to evolve. People doing things that are related to the original project, but are not the original project. This is a good sign of success. An ecology of associated activities evolves. It might be slow at first… someone blogs about what you are doing, someone else starts demoing the project to others… etc… its the first stages of adoption..you don’t have a large market share at first and your product is still young…so the first people you have in the community are the early adopters…they fill in the gaps they see as necessary which, at that stage, aren’t that many…but they also put in the energy to do it…they are the passionate ones.

Then things start to get serious. You actually might have people asking if they can hire someone to do some dev. Or maybe they want to use the product and they don’t know how to. They might not even know how to install it. Who knows?

You can manage this for a while, somehow, but then you are also growing and you think…hang on…someone should be paying for all this….

And you start thinking about services.

At that point you have to clear your schedule for a few days and step back and have a think….the basic problem is this…

If you offer services, and lets be explicit about this – most of my thinking around this (though not entirely) is linked to hosting services for open source platforms – then you will fulfill a need for your growing community. That is true. But also there is a cost.

First of all, the community has been stepping in and filling out some of the stuff that needs to be done… when you start offering services to the community, then your relationship with them fundamentally changes. They are now your customer. And as such they have certain expectations for service and support etc. They want to be able to get something very explicit from you and they want it in a timely fashion and they want it done in a professional fashion. They may even want you on the end of a phone at any hour should something go wrong.

This type of relationship is entirely inconsistent with the idea of a community. This kind of relationship is a service – client relationship. I know that many in the publishing world (to throw a rope around it) consider this kind of grouping to be a ‘community’ but it isn’t. I have heard of such groupings being referred to as ‘community meetings’ but the description of these events sounds to me more like a congregation of Stockholms Syndrome sufferers.

Community, is all about good faith transparent collaboration. Where everyone is working together towards the same vision. It is an opt-in situation and its important that the power dynamics are level. All community members should be equally valued. One community member cannot, and should not, be allowed to lord it over the other.

Service – customer relationships are not this. I know some modern blahblah language will try and frame it this way but its all semantic slight of hand. Building a community is not the same as building a customer base. The tone of the relationship is substantively different, the power dynamic is also completely different, and they do not mix.

So, when you set up a service you are changing your community. They are going to expect different things from you and you are going to have to do it. No more ‘we are all in this together’..rather, you are now on the end of a rope and they have every right to pull on it.

IMHO this is not good if what you want is a community. This will cause you and the community pain. This hybrid service-community approach will tear at the fabric you have created and probably make you miserable.

If you don’t want community, as I have described it, then go for it. Become a service organisation. But we aware there are other costs… first… members of your community, important members, may have been thinking of doing the same thing. Now you are in competition with them. You are in competition with the very people you were once working with. Not only that, its hard for that to go well because you ‘are’ the project as well as the service. Which puts you in a privileged competitive position. Those that go up against you are probably going to either drift away or, potentially, end up getting pretty passive aggressive.

So even if you do go down the service path, and abandon community, its going to be weird and rough.

Anyways…so thats my 2cents. If you are going to develop a community and are thinking about services by advice is that if community is really important to you then let the community supply the services… don’t fret it…work with them and who knows, maybe they will help you with sustainability also. AND…while you are at it… think about intentionally designing your community with thoughts to the community providing these services going forward…they will be better at it and if the community goes into competition with each other then that is healthy – shows your impact is growing and also the more services there are the more your impact will grow…

Pondering Bizness Models

Pondering Open Source business models currently. I can see that there is some interesting possibilities for generating revenue around building platforms with PubSweet. The interesting thing here is that PubSweet is essentially an open-ended proposition. You can build anything on top of it. Which also means that there is quite a wide open space for development opportunities. These are not even, potentially, limited to scholarly communications or publishing in general. You could use, as the French Gov is currently investigating, use PubSweet to build out ‘other’ kinds of workflows outside of the publishing sector. As in, with this example, workflows for processing judicial reviews.

That means, if we can generate awareness of the offering, then we have quite a wide space for generating business via bespoke platform development. Secondary incomes, in years to come, can then also support this approach in general ie. helping other orgs to develop on top of PubSweet with workshops, training etc

This is different to other Open Source projects I have been involved with. In the past I have built singular platforms. Booktype is one good example – a python (Django) based book production platform. In many ways a very functional but less elegant predecessor to Editoria.

So… Booktype is a single proposition. It is one set list of features baked into a single platform…. what is interesting to me is that the business opportunities here look quite different. Essentially, since you have to maintain one offering you don’t have the same kind of bespoke development opportunities you have with PubSweet. Bespoke dev for something like Booktype has a very narrow bandwidth – you can only change the main app so much at the request of a client. You don’t build platforms, in this scenario, but you build ‘deltas’ ie you build just the small difference between what you have and what the customer wants. All the time you must be mindful, when doing this, that when you make those changes you are fundamentally changing the initial offering. If you do change it to a substantive degree, you risk alienating your current users unless you are *very* sure these changes are what the majority of users want. The trick being also, that the larger the user base grows, the more difficult this is to determine. Even with a smaller user base you risk losing users if you are ‘too beholden’ to what a single client wants.

So… there are some other options for generating a model here… i am necessarily discounting funding, this is not a medium or long term sustainable model unless you are in a very privileged position which is necessarily a rare circumstance. … off the top of my head these models look (at least) something like this:

  1. monster client – find one monster client that is in such bad need of what you are making, and has such deep pockets, that you just keep building stuff forever. Hard to find.
  2. pay for use – a hosted deployment situation that is either a single instance per client, or a (so called) multi-tenanted solution where you charge per user (or some such). Problem here, is that people don’t want to pay much to use software, especially open source software unless you are solving a really big problem and they cannot possibly live without you.
  3. membership – a membership based program where you charge on a tier according to the capacity of the org… for example, small orgs contribute a little, larger ones pay more…in this situation you must be critical to their workflow if you wish to charge anything more than a trivial amount. If you are critical to an org, you can expect (or at least try) to ask more for the membership.
  4. Services – this one is very open ended and you can be entirely creative. Services might mean support but this kind of service will not work unless you get to a threshold that means you can afford to cover the costs of providing that support. Very difficult for a software starting out. On the other hand, you can also think about services a lot more broadly. Events, for example, can be considered as services. Consultancy also. Podcasts perhaps. One very good example for me, although I don’t know how much they generate from it, is Loomio – its an open source tool for collaborative/distributed decision making but the org that makes it also offers consultancy on how to change the culture of your org to make better devisions. Pretty interesting.
  5. Complimentary revenue – im throwing this in there because I don’t actually know of any good examples but I am thinking of the McSweeney book publishers that generate a lot of revenue to support their core business by selling pirate clothing (and other stuff). It is a pretty interesting idea. Why limit the revenue generation to what the software does? Why not do an audit of the skills in your team and brainstorm what you could do to make money.

All of the above are of course possible for a solution like PubSweet, but frameworks like PubSweet have more options that a ‘single offering platform’. At least, that is the way it looks to me now. It doesn’t mean the future is bleak for a platform type offering, but the scope of offerings for generating income is potentially more limited.

Working with The British Library

And in my other life… Book Sprints is just so rockn…our forst Book Sprint in Doha happening right now AND its with the British Library…amazing….who am I?! crazy…

https://blogs.bl.uk/digital-scholarship/2019/09/labbers-of-the-world-unite-to-write-a-book-in-1-week-through-a-book-sprint.html