We used two systems to write the Cabbage Tree Method book – Booktype and Editoria.
Editoria was created using the Cabbage Tree Method. The following are some screenshots of Editoria with the book in production:
and finally…
Yes, here it is. The 0.1 version of the book on the open source collaborative product development method known as…. The Cabbage Tree Method. It’s an early release just for you. I’d love comments (use the comments on this post for this version).
Download – The Cabbage Tree Method (PDF) v0.1
EPUB, WWW and printed version coming soon…. CC-BY-SA. Print it off and sell it if you will. Make a million bucks and my day at the same time!
The book was written and rendered in entirely open source tools including Editoria and Vivliostyle. HTML all the way home…
http://www.cabbagetree.org currently points here but will become a proper home for the book very soon.
pssss…. I don’t use social media. Please promote this with any and all avenues open to you! thanks!
Pepper Curry has been adding color to the pics for the book. They look great!
Some of my favorite photos of people collaborating in projects I’ve been involved with over the years. I might be a niche audience but I really love seeing interesting photos of people closely collaborating. I don’t know what it is, the intensity, the immersion, people side by side ‘in it’ together…its just so fascinating….
Some years ago I helped start an activist organisation named HelpB92 in Amsterdam. It was a strange road to that point. I had left my previous home for 2 years in Adelaide and headed to London to find my fortune. I was all kitted out with a one-way ticket, an Apple Centris wrapped up in a cardboard-and-gaffer-taped box without a monitor (it was too big to carry), and (almost) $1000 Australian dollars (all the money I had in the world after I sold my mountain bike). I was 30, the big plan was to go to London to make coffee (for other people). I had it all worked out, except maybe the Visas and stuff, y’know… I had most of it worked out.
On the way I was to stop off in Amsterdam for a conference. It was the Next 5 Minutes conference at De Balie. All about tactical media.
The net was pretty new (1999) and activism had not really found its place yet in the new medium. I was there as a practicing artist (r a d i o q u a l i a) to advocate for streaming media, ‘internet radio’ as it was thought of then, as a way art and activism could inhabit the net. I crashed on a friends floor for the duration sharing it with very young RTMark, later to become the Yes Men, as it happens (they did their first performance at that event). Also at the event friends (Micz Flor and others) took care of this poor antipodean and gave me food tickets they were given as presenters so I could save some money. It was pretty cool.
At the time Amsterdam was a safe harbor for activism. Pirate radio and tv proliferated, often resident in the many active and interesting squats that populated the city. The place was alive.
After that conference, I got a little sick. Just a cold but I was worn out. I had to buy a ticket to London and was trying to work out when I should go. I happened to be walking across a square (Nieuwmarkt) on a cold rainy day and Geert Lovink, something of an internet hero to me, saw me and asked how I was. When he gathered I was sick he offered me his place to stay since he was going away for some months. It was incredibly generous (I even remember, knowing I was a radio junkie, he put an FM radio under the pillow, such a nice touch) and I hunkered down for a few days, not wanting to stay too long in fear of taking advantage of his generosity.
During that time Nato started bombing Serbia. It was a weird feeling. I remember feeling so strange that I was standing on the same soil as a war. It’s not something New Zealanders are really used to. Anyways, Geert contacted me and a few others and said I should scoot it down to De Balie and join a meeting to see what could be done. I went down there and found this powerhouse of amazing people ready to talk about what to do. They included Sjoera Nas & Maurice Wessling (who later together founded Bits of Freedom, the EU equivalent of the EFF), Geert, David Garcia (founder of Next 5 Minutes), Gerbrand Oudenaarden and many others.
Together we felt the one thing we could do was to keep a spotlight on free media in Serbia, so we co-founded HelpB92.
We were a motley crew with good ideas and good intentions. The internet was barely explored for activism at the time so we had to more or less make up how it might work. Our main aim was to keep B92 (a Belgrade-based station) and other free media in the international media spotlight so no one ‘disappeared’.
Our strategies were thought up on the fly. We did the typical stuff like making interviews and contacting the mainstream media with information etc. But we also did stuff that seemed way innovative at the time…like making animated gif badges for friends and supporters to put on their websites.
Seems crazy now but back then this was an unknown strategy. We were really innovating without knowing what would and wouldn’t work.
Since most of us had connections to either art or activism, or both, we combined these worlds together. We were part of efforts to get Serbian artists invitations to conferences and residencies outside of Serbia and then holding on to them once they got there. Gordan Paunović was once such person, the program director for B92.
Once he arrived in Amsterdam we also started organising online streamed events with famous artists to raise money and lift the profile even more. One such event I remember he and I ran from the Kunstradio offices in Vienna. It was called NetAid (not the UN event of the same name) and we did a series of 5. We streamed in artists from all over the world into one co-ordinated stream. The software didn’t really exist for this kind of thing so we had to do it partly old skool with hardware mixers and also write our own software. It was pretty sketchy but it worked.
During the bombing Geert made contact with Radio21. They were a Priština-based station managed by Kosovo Albanians that was in exile in Skopje, Macedonia. At the time most people thought Macedonia was next on the list for war since there was a lot of unrest and they didn’t appreciate the Albanian refugees flowing across the borders from Kosovo. Geert said I should go down there to help them out…waaaaaaaat? I was a milk and cookies ‘technician’ (artist really) from little ole New Zealand…what on earth am I doing gong to a ‘war zone’. I thought about it and I didn’t want to go… but I thought if they thought I could help then I should really go. It was bent logic.
Anyways. I remember searching for flights. Funny thing was, no airline was going near the war zone. Makes sense. I finally found an airline that did and nobody had heard of them. I still remember the name of the airline – Air Avioimpex. I told Gordan I was going and he asked how. When I told him the name of the airline he went pale…I can almost remember his words verbatim, it was something like
oh no….they are really old planes without the best electronics, and the problem is the airport is between two steep cloudy mountains and sometimes they don’t make it…
I was feeling out of my comfort zone. Anyways, I got some tech together, they wanted me to be the streaming media guy down there so I got some tech – mics, a small hardware mixer etc. I remember going to the airport, I was flying from Vienna, and it seemed like there was a ladder going up the back of the plane where we were supposed to go. I climbed in. When I got inside it I felt like there was a soccer game happening…it was kinda chaotic, with people running around, a soccer ball somewhere. It didn’t feel terribly well managed.
Anyways, I went to sleep. I had not had much sleep the nights before so sleep was actually easy. I awoke to feel the plane descending fast and looked out the window. I could only see whiteness outside…oh no…I wished I had slept longer…
Anyways, we made it through the mountains and I remember seeing the airport and it was just military planes and armored ground transportation. Somehow I made it to the town center where I was to meet the Radio21 crew. They were happy to see me and I worked together with them for a few weeks. The main outcome being a rather innovative system we set up where reporters could go down to the refugee camps with a phone. They would call us, we would record it as they interviewed people, and then we would upload the interview to the net. Radio Netherlands then picked up the files from the net and broadcast the interviews on Shortwave over Europe. The thing was, back then, there was no good internet or even good streaming tech to stream these interviews. We used a combination of mobile phones, FTP (putting files online), and Shortwave to get these interviews into Kosovo so the families of those in refuge would be able to tune in and know their families were ok. At the time it was very innovative.
I remember a few things from this period. I remember the really cool Albanian bunch inviting me to drink at Albanian bars. “Aren’t they attacked by bombs occasionally?” I asked. “yes, but you get used to it” was the reply…
I remember a bomb going off across the street from the offices. It was planted in a trash can. I was downtown at the time but apparently two kids lost their legs.
I remember hearing a thick oily sound in the sky at night and in one moment realising that was the sound of planes on their way to kill people.
I remember a good buddy – Dmitry – telling me that I should choose to leave at the right moment. The wrong moment was when all the transportation was canceled and you couldn’t leave even if you wanted to.
I remember one morning the peace talks failed. I went to the train station and the guy at the ticket office was very sweaty and stressed. “Can I get a ticket to Greece please?”. “No, the trains have been canceled” he replied. “Can I get a plane ticket?” – “No” he said, stroking his sweaty bald head, “The bastards have closed everything”.
Hmmm….
I walked out of the train station and saw a guy standing over by a taxi. He saw me….I walked up to him and asked him how much to get to Greece, I think it was 600km away or so. He didn’t speak much English but communicated it was 1 DM (Deutsch Mark) per KM. Absolute robbery. I shook my head and walked away.
I came back to him and said ok.
We drove to the border. On the way out dozens of Nato trucks were coming the other way. I was relieved to be driving away from the dodgy border on the other side of Skopje.
I had to cross the Greek border on foot since the (very kind) taxi driver didn’t have a Visa. The border guards were very freaked out. What was someone doing crossing on foot and why was I here and not in New Zealand!? I had no good answers. They let me through.
I made my way to Athens via train from Thessaloniki. I went to the nearest hotel, booked a room and drunk my last 200 DM in cocktails.
In the end, I never actually made it to London to make coffee.
And another chapter…
The first group of use case specialists, the people that designed the software, will be the early adopters. They’re good allies to have because they have buy-in. They’ll be enthusiastic and eager but patient when using the software in its early stages. Get them using the software as soon as it is viable so you can all learn and improve the software together.
After several iterations of testing and development, there’s a solid application. What’s next? It’s time to take the software to the rest of the world.
How can the Cabbage Tree Method be used to migrate a product from the small group of early adopters to a larger base of users? Through diffusion, a strategy for stimulating the adoption of a product into a wider market by taking advantage of the networks of the early adopters.
It’s a simple idea, much like adding layers to an onion. The first adopters of the software can convince others on ‘the next layer out’ to adopt the product. They’re the software’s evangelists. They’ll help introduce the product to the next level of adoption. They’ll turn their friends and colleagues into users, who in turn become advocates, and so on.
The diffusion strategy has been proven out in the real world. The following example comes from the medical sector, which I learned about first hand from John Abele of Boston Scientific.
Early in his career, John was involved with developing cutting edge (or non-cutting edge, as the case may be) technologies for non-invasive surgery. Today, non-invasive surgical techniques are commonplace. Back then, however, surgery was invasive by definition. Back then, talk of non-invasive instruments for surgery would be like talking about screen-less phones today. Imagine trying to sell that.
Because surgery was defined by ‘cutting’, the market was hostile to this new idea. So John had a hard time trying to generate adoption for a technology that he knew could transform the medical sector and help millions of people. As he writes:
We were developing new approaches that had huge potential value for customers and society but required that well-trained practitioners change their behavior. … Despite the clear logic behind the products we invented, markets for them didn’t exist. We had to create them in the face of considerable resistance from players invested in the old way and threatened with a loss of power, prestige, and money.
Smart people who are under the painful burden of outdated technology often resist systemic change. Why? Because it requires them to alter their established ways of working. This, rather normal, resistance to change, can be a huge obstacle to adoption.
In John’s case, he drew on some insights he had gathered early on in his career from Jack Whitehead, CEO of Technicon, a small company that had the patent for a new medical device. When trying to bring this product to market, Technicon also had the odds stacked against them. No one, from the lab technicians through to the professional societies and manufacturers, wanted anything to do with it. So Jack drummed up some interest from early adopter types and came up with a surprising next step. He “told all interested buyers that they’d have to spend a week at his factory learning about it.” Further, they would have to pay to attend.
That sounds like an odd sales pitch now, and back then (early 60s), apparently it sounded a whole lot more crazy. Nevertheless, Jack convinced a handful of excited early adopters to seize that day and brought them into his factory.
During that week, the early adopters were not treated like customers but like partners. They were part of the team. They came to know each other, they worked together, they helped to shape the product further. They became the team. Sound familiar? This is pretty much how CTM works. The users become the team.
As John says:
When the week ended, those relationships endured and a vibrant community began to emerge around the innovation. The scientist-customers fixed one another’s machines. They developed new applications. They published papers. They came up with new product ideas. They gave talks at scientific meetings. They recruited new customers. In time, they developed standards, training programs, new business models, and even a specialised language to describe their new field.
This meeting of once potential customers, now team members, not only contributed to the design of the technology but then took it out into the world and fueled adoption and interest in the product. What had humble roots with a group of early adopters was on its way to creating large-scale change.
John witnessed this process and realised it was essentially strategy, not whimsy: “[Jack] was launching a new field that could be created only by collaboration — and collaboration among people who had previously seen no need to work together.”
John went on to form Boston Scientific and refined this strategy further with Andreas Gruentzig when introducing the balloon catheter to a hostile and uninterested market. Again, he was successful in catalysing large-scale change.
Astonishing.
But, on reflection perhaps there are no surprises here. You could have told the same story about any number of successful Open Source projects. Indeed, as John also reflects:
Just as Torvalds helped spawn the Open Source movement, and Jimmy Wales spearheaded the Wiki phenomenon, Andreas [Gruentzig] created a community of change agents who carried his ideas forward far more efficiently than he could have done on his own.
The strategy in all these cases started with a simple idea – to create a community of change agents. John Abele did it with surgical instruments, Linus Torvalds with a kernel, and Jimmy Wales with information. Now we need to leverage these exact same strategies to fuel the adoption of world beating user-facing open source products.
Diffusion works because the users are the community and they feel ownership of the processes and the result. This is exactly what the Cabbage Tree Method develops in the Design Sessions. To take the product to the next level requires leveraging this shared ownership by working with the initial group of users to bring in the next layer of users. Each group, in turn, is empowered to take the product into the world and convince more people of its usefulness, perhaps even drawing them into future design sessions.
Another chapter from the forthcoming book
Imagine a bunch of people in a room, all sitting around a table. There are some whiteboards in the room, and coffee, sticky notes, and maybe even a data projector, litter a table. All of those people, except one, share a common problem and they want to create new software to solve it.
But where do they start? There are no developers here … what’s going on? One of them, the facilitator, steps up and initiates a short period of introductions and then asks the question “What is the problem?”
From this, a process unfolds where the people who need this new software (let’s call them the use case specialists) explain all their frustrations with the ways things are done now and what could be better. It is a wide-ranging discussion and everyone is involved. At the facilitator’s prompting, someone jumps up and draws a straggly diagram of a workflow on one of the whiteboards to get their point across. Another pipes up to add nuance to one part of the diagram because they fear the point wasn’t adequately understood. There are some quiet moments, some discussion, lots of laughter, a break for lunch. Plenty of coffee.
Throughout the day, the group somehow (the facilitator knows exactly how) evolves their discussion from big picture problems and ideas to a moment where they are ready to start designing some solution proposals. The facilitator breaks them into small groups and each group has 45 minutes to come up with a solution. When they come back, each group presents their ideas. Some of the ideas are very conceptual, almost poetic. Other ideas are very concrete and diagrammatic. Everyone thinks carefully about the merits of each proposal and what it is trying to say. Discussion ensues. Members of the group ask clarifying questions. After all the proposals are made, they decide on an approach.
In a short time, they have agreed on a set of requirements for software that they have consensus on and all believe will solve (at least some of) their problems. They take photos of all the whiteboard diagrams and document the design agreements thoroughly, creating a Design Brief. At the end of the day, they walk out the door and the design session is over.
The next day the Build Team, featuring user interface (UI), user experience (UX), and code specialists, looks over the documentation with the facilitator through remote conferencing. They discuss the brief, what is clearly defined and what is still to be defined. They work through the issues together, jamming out approaches to open-ended questions which are both technical and feature-focused. The session is not long, perhaps two hours. It’s a lot of fun. From this session, the Design Brief is updated with the decisions. Many technical solutions are left wide open for the code specialists to think through and solve over the next weeks. However, the code specialists can, and do, start work immediately, though the UI/UX specialists add mockups to the documents over the next days. The team works things out on the fly where necessary and gets onto it. Over the next weeks, a few questions to the use case specialists surface – these are either asked directly or through the facilitator.
The use case specialists reconvene six weeks later with the facilitator and are presented with the working code that has been created by the build team over that period. Everyone is amazed. It’s just as they imagined, only better! After seeing the working code, they each have further, exciting, insights into how this problem might be solved. The facilitator steps up and they go through it all again to design the next part of the solution. Everyone is bursting to have their say.
The design-build cycle is repeated until they are done and the software is in production.
This is the Cabbage Tree Method.
The Cabbage Tree Method (CTM, for short) is a new way to create open source software products. With CTM, the people who will use the software drive its design and development under the guidance of a facilitator. It’s a strongly-facilitated method that generates and requires immersive collaboration.
You can think of CTM as a new branch on the Systems Development Life Cycle (SDLC for short) tree. Some popular SDLC methods include Spiral, Joint Application Design, Xtreme Programming, and Scrum (some of which conform to the values of the Agile Manifesto – see http://agilemanifesto.org/ for details).
Unlike the various SDLC methods, CTM is specifically aimed at the free software/open source sector. In that sector, the cultural rules are quite different from environments where teams are employed to work within a more formal business or corporate structure. However, CTM differs from open source processes that have embraced developer-centric solution models, thanks to its focus on users designing the software with a facilitator as an enabling agent.
What also sets CTM apart from other methods of developing software, is that it doesn’t have:
This process isn’t about development procedures that represent the user at a distance. It’s about communicating and collaborating with the user at the center of the process. It’s not a question of profiling a so-called user, or turning them into an avatar or proposition, or trying to generate empathy with them from afar. Rather, a core requirement of CTM is to directly involve in the design process everyone who will use the system. The idea is that if you want to know what the user wants, don’t imagine their response. Ask them.
Like most modern SDLC methods, CTM is iterative and has clear cycles. Each cycle consists of a Design Session followed immediately by a Build Period. These cycles repeat (design, build, design, build, design, build etc) until the solution is complete.
The specialists most in demand for the Design Sessions are the use case specialists – the users themselves. The Design Sessions are always in person – they don’t work well with remote participation. Each design session can be as short as two hours, or as long as one day.
The general principle of the Design Sessions is that all users affected by the software must be present at the appropriate moment – either in total or as a representative group. Without their presence, a solution cannot be developed. A fundamental rule of CTM is that no one speaks for the users other than the users themselves.
From each Design Session, a short brief is created that describes what has been agreed to, what is absolutely required to be done in the following build period, and what is left to be solved during the build period.
The Build Period takes place immediately after the Design Sessions. The build period can occur remotely and may take two to eight weeks, perhaps longer. Building is the job of the UI/UX and code specialists and it is here they can both be creative and exercise their User Interface (UI for short), User Experience (UX), and programming skills. Use case specialists don’t participate in the Build Period but may be consulted for clarification during this period.
Before the Build Period begins, each of the build team members receives for consideration the initial brief that was created during the Design Session. The Build Period then begins with a meeting where the code and UI specialists discuss the brief, decide on an approach, and together develop solutions for any outstanding issues. This may include solving some complex feature, technical, and usability problems – essentially working out how to achieve everything the users have already decided, plus designing what is left over. Then briefs are written and agreed upon, mocks done where necessary, and building begins.
I’m producing a book on collaborative product design together with Scott Nesbitt, Pepper Curry and Raewyn Whyte. As it happens we are all New Zealanders and live either in Auckland or north of Auckland (I live in San Francisco but have a place up north).
A cabbage tree is an actual thing. A tree, in New Zealand, that I used to think was ugly, but now I’m totally in love with. It is an awesome tree. As it happens there are heaps of them on my property so here a few pics to educate those poor souls who have never before come across a cabbage tree.
They inhabit roadsides and hillsides in Northland.
Although they are pretty lonesome trees, there are a few cabbage tree forests on the east coast that are amazing.
And their leaves are pretty crazy.
Anyways… in case some day you are asked ‘why the Cabbage Tree Method?’ you’ll be in the know…for my part I’ll tell them its some crazy metaphor and see if I get away with it…
