I wrote a brief post on whats happening with Editoria for the Editoria site. Complete with demo vids.
Demos made by Alex Theg as a backup for demonstrations (in case wifi fails etc). They have no sound and merely display the core INK features at work.
Creating a Recipe from Existing Steps
INK and Editoria Working Together
I’m on my way to SSP in Boston. It was a quick 2 hour stop in San Francisco from NZ, just long enough to get a shower at the airport! Such a nice thing to do on long-ish hauls.
The plane is delayed, arriving at about 2am, fresh and ready for an 830am (3 hour) panel to talk about open source and scholarly publishing.
My neighbor (in NZ), James came over this morning. We went for a walk around in the bush on my property. It was a rainy but lovely morning.
I’ve been sick the last week and slowly on the way to recovery. Thankfully today I was able to pick up some manuka honey that comes from the hives I have on my property in NZ. The hives are looked after by the good people at Coogzen Lodge down the road and I get a % of the honey produced. Works for me…seems this year they harvested 85kgs of honey, which means I get 10kg!
The honey is manuka, which is the best honey ever. Legendary for its healing properties but also just the best tasting honey around. Pictured here are the actual manuka bushes that the bees have been feasting on.
And a quick shot of the hives, note the young cabbage tree in the foreground!
I just had my first lemon and honey drink for the season. Feel better already!
The following is an outline on some new tools for the Cabbage Tree method. These proposals are designed to:
- Explore how the Cabbage Tree Method (which is largely about facilitated product design and places the user, as a use-case specialist, at the center of the solutions model) can scale its processes
- Generate some learnings to help iterate towards a Cabbage Tree model that can also build community
After taking this to the Shuttleworth Gathering, and then unpacking early thoughts at the PubSweet Global Meet, I proposed that we experiment in a series of iterations to extend the Cabbage Tree Method and generate new ideas. Everyone was open to it and so we will try a first experiment, and then reflect on it and iterate forward.
So, a brief framing.
Current Open Source community driven solutions models look something like this:
Developer ------------------------> User
In this scenario, the User is slightly parasitic and the naming is right. The user uses the product of the developers.
In the Cabbage Tree Method, we have re-positioned the ‘user’ as a use-case specialist. They reside at the beginning of the process.
User ------------------------> Developer + UX expert
The user (use-case specialist) designs the product and then the developers and UX people improve the design, and build the product.
What has been pointed out to me (in Athens), is that the developer is featured in the Cabbage Tree Method (CTM) at the beginning by me -since I am the facilitator of the design process and I have some technical knowledge. So the Cabbage Tree Method was born already with a model that isn’t as purely user-centric as it proposes. I’m grateful to the PubSweet Global think tank for helping me understand this. A consequence of this observation is the need to understand that the developer (as expert) can play a very interesting role in designing the product. The developer essentially keeps the design ‘on the rails’ and within the boundaries of the possible and the doable. This is very important, since CTM is about efficient processes as much as it is about good design and good software.
Cross Functional Collaborative Groups
So, the next iteration will bring the developer (code specialist) and the UX specialist to the beginning of the process with the user. This will be the basis for a cross-disciplinary collaborative group that will design the product together.
User + Developer + UX expert ------------------------> Product
The core players, and some of their challenges, are as follows:
- Use Case Specialist – the primary voice in the design process. They must say what they want but listen to the advice or thoughts of the UX and code specialists as to what is possible and doable.
- Code Specialist – must play a mentoring role in the design process. Keeping an open mind to approaches they haven’t considered before. One of the big challenges is for the code specialists to accept what the user wants even though they disagree.
- UX specialist – they must help make the product look and ‘work’ better than expected by everyone else involved! Care must be taken not to override the users’ requests. This role, like that of the code specialist, is very much a mentoring/guiding role and the UX specialist might very well know where the user is heading with a design but must allow the user to get their at their own pace.
- Facilitator – for all this to work, a facilitator must be present at all design meetings. The facilitator is there to moderate human dynamics and ensure everything proceeds on an even keel. The facilitator should not play a role in design.
In previous iterations of the CTM, I played the role of the facilitator and a bit of the ‘code specialist’ (really a technical domain expert). In the next iterations, we disambiguate this. This will also hopefully allow the model to be more easily replicated.
In the current CTM, all design process take place in real space. However, this does not scale. We need to find more effective ways to enable small teams, rather than one big team, to break off chunks of the problem and work together. To do this we will bite the bullet and try working through remote technologies. In this way, our UX specialist (Julien) in France, can attend alongside our code experts (Slovenia, Kenya, UK, Athens), alongside the use case specialists (mostly in California) with me facilitating from where ever I am! In simple terms, we have to make this work.
So we will look to use Jitsi for open source video conferencing, and ahn open source collaborative online whiteboard (there are plenty). Remote participation loses a lot of nuance but I am hopeful we can make this work with a small team if we are disciplined about the process (this is where facilitation kicks in).
Iterations on CTM
So the first step is to try this out. We have started work on a Journal platform so we will try one meeting like this and see how it goes. I think the balance will be something like:
2 x code specialists
1 x UX
4 x use case specialists
1 x facilitator
… probably we start this in June. Then we will reflect on it and tweak the process as we go. I’m not convinced this will reveal the secrets to how to build open source products as a community, but it is one step further in that direction. I am sure we will design good products this way, but working out how to make CTM scale and how to open it up so it can become a self-replicating community is going to take some time. Still…I feel we are on the right path (and an interesting one!).
In NZ for a week to renew my passport. Winter is here but it’s sunny and warm. Manuka is out in bloom.
Shuttleworth Gatherings are always fun. Fun, intensively thought-provoking and tiring. At each event, we get the opportunity to tap the minds of the fellow Fellows on a topic or issue we are working on. What follows is an hour or so of amazing insights from all sorts of smart people with very deep, diverse, insights into the issue. I have been to 4 Gatherings now and these sessions have deeply affected how I approach things and what I do.
At the most recent Gathering in Vancouver (early May) I pitched the following idea to about 14 sharp minds.
Aim: How to build community around Open Source Software Products
And I loaded it with the following assumption…
Assumption: The developers and users are not the same people.
My question to the group was set up with some background to my thinking about open source culture on which I have written a lot recently on this blog. The main idea being that open source has been great at developing infrastructure and developer tools but not user-facing products. The problem, as I see it, is that the ‘user’ (use-case specialist) is not central to the culture in these cases, rather the projects are developer led. So, if the use-case specialist was central to the culture, how would this work?
My two questions to the group were:
- why would people want to be involved?
- what would that interaction look like?
The chair pictured is one of the ‘artifacts’ that came out of the session. I took a photo because the session was super-helpful for me and led directly to a conversation a few days later in Athens with the Coko PubSweet team.
I haven’t had time to fully distil and unpack the Shuttleworth session, but there are a number of phrases and thoughts that are hanging around in my head that feel like pieces to a puzzle which I have yet to solve…. Some of the pieces as they exist in my head now:
- attract/motivate people to be part of the project, not just part of the product
- be community-centric (as opposed to dev or product-centric)
- in a diverse collaborative group we must learn to speak each other’s domain language
- work from a shared passion, not a shared need
- such communities aren’t for everyone and we should be ok with this
- success must be a shared metric
- make it fun
- make it something that is a shared journey/adventure/exploration
- the journey must be social
- contributions have equal but different weights
- developers need to understand the user commitment
- equality in difference
- facilitation is hugely important
- get away from the idea of someone making something for someone else
- help people understand the value other roles can bring to the process
- recognize different power dynamics
- celebrate people for engaging with each other
- reduce barriers to entry across the board
- instinctive not explicit
- community is core for figuring out solutions
- there is magic in doing something new or in a new way
- remove the community and all processes from the world of tech
- keep the conversation really big
- shared itch, not the same itch
These all link to more coherent and substantive thoughts but they are nice fragments for me to preserve. When I have pondered the matter some more I will draw these themes out in more depth.
What does it mean for me now?
Despite having to process this a little, I have already moved forward on some of these ideas. In Athens, we just finished a meeting with the Coko PubSweet crew. In this meeting, I proposed we discuss how we can get ‘users’ (use-case specialists) and ‘devs’ (code specialists) to work together in close collaboration. This would not answer the question as to how to make a community around open source products but it might give us some learnings and some clues. The idea we came up with is to form small work groups of 2 devs, 2 users, a UX person, and a facilitator – to work together on a trial basis. This would most likely have to be done remotely, which is challenging but the only possible way to make this happen at this moment since we are working with a very distributed team. That’s ok because that is a realistic reflection of the distribution of open source projects anyway.
So we will try this out with the Journal platform we are building. I think we will try it out with one team and reflect on it. See how it goes. From this experience, we will learn some things and take that forward in another iteration…
I was really happy with the discussion at the PubSweet meeting and it reflects the awesome bunch of folks we have at Coko. Really cool people.
Anyway …if the above makes sense to you in its partial, scratch out, form then please reach out to me with your thoughts.
I’d like to thank all the Shuttleworth Fellows that were at the session including Sean Bonner, Anasuya Sengupta, Tarek Loubani, Alasdair Davies, Ugo Vallauri, Seamus Kraft, Peter Cunliffe-Jones, Madeleine Ball, Luka Mustafa, Aaron Makaruk, Gavin Weale, Kathi Fletcher, Jesse von Doom and Helen Turvey. An amazing bunch of people.
I just finished a 3 day meet in Athens with the PubSweet team.
It was a fantastic meeting and we covered a huge amount of interesting ground. Most importantly we discussed:
- the remaining features for a PubSweet 1.0 (due end of June)
- some future ideas for PubSweet 2.0 (possible GraphQL Apollo integration)
- a demo and discussion around the latest Editoria (looks amazing!)
- a workshop on how to think through Journal workflows with our decoupled approach
- and a great discussion on how we could start growing a community model around Cabbage Tree Method principles (moving towards Cabbage Tree 2.0!)
We also looked at the new Athens office, and meet with Vasilis who is managing the production servers for the forthcoming UCP Editoria tests…
Now off to New Zealand! It was a really fantastic week!