Publishing Innovator. Surfer. Ponderer. NZer.
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…
The below is an excerpt from a chapter on facilitation for the forthcoming book on the Cabbage Tree Method (collaborative product design). The image is by the wonderful Pepper Curry.
Facilitation is a key ingredient for the Design Sessions. In fact, no group should attempt to use the Cabbage Tree Method or run a Design Session without a facilitator.
The facilitator is part of your open source team and should not be part of (if possible) the user group that needs the solution. This neutrality frees the facilitator, as best as possible, from existing ideas, and organisational politics and dynamics. In turn, this enables the facilitator to read the group clearly and interact freely.
You will need post-it notes, a large whiteboard and markers (or large pieces of paper).
Facilitation is both an art and a science. It’s difficult to master both aspects of facilitation. If you’re new to facilitation then it’s best, if possible, to watch experienced facilitators in action and try some small experiments first. I strongly advise against learning facilitation from a book. There’s no substitute for experience.
Having said that, here are some things to remember when facilitating Design Sessions. They’re intended to help you formulate an approach to this process. They’re not intended as a facilitation ‘how to’:
Build trust before products – As a facilitator, your job is to build trust in you, the process, the group, and the outcomes. Each time you make a move that diminishes trust you’re taking away from the process and reducing the likelihood of success. You must put building trust, working with what people say and towards what people want, ahead of building the product. Trust that the product, and a commitment to it, will emerge from this process, and it will be better for it. I am thankful to Allen Gunn for this wisdom made very kindly to me many years ago.
Change is cultural, not technical – Too often people propose technology as the mechanism for change. Technology doesn’t create change. People create change, with the assistance of technology. Make sure the group is not seeing technology as a magic wand. The group must be committed to changing what they do. The what they do shouldn’t be posited as a function of technology. It’s their behavior that will always need to change, regardless of whether there is a change in the technology they use. Behavioral and cultural change is a necessity, not something that might happen. The group needs to recognise this and be committed to changing how they work. This also means that they must commit to using the solutions you design together.
Even the best solutions have problems – Understand and embrace that even the best solutions, including the one you’re representing, will have problems. There is no perfect solution. If there is then, inevitably, time will make it imperfect.
Leave your know-it-all at the door – If you’re part of a product team, then you may be expected to be somewhat of a domain expert. It’s not possible to leave that at the door, of course, but you should be careful that you don’t use this knowledge as heavy handed doctrine. Instead, your domain knowledge should manifest itself in signposts, salient points, and inspiring examples at the right moments. These points should add to the conversation. They shouldn’t override the conversation. Don’t overplay your product knowledge and vision. You’ll lose people if you do.
Give up your solution before you enter the room – If you’re part of a product team, it’s a mistake to enter into a Design Session and advocate or direct the group towards your product or your vision for a solution. If the group chooses a technology or path you don’t have a stake in, then that’s fine. The likelihood is that they’ll choose your technology or approach, otherwise you wouldn’t be asked to be in the same room with the group. However, if you facilitate the process and drive them to your solution you’ll be reading the group wrong and they’ll feel coerced. You must free yourself from this constraint and be prepared to propose, advocate, or accept a solution that’s not yours or which you didn’t have in mind when you entered the room. This will not only free you up to drive people to the solution they want, but it will earn you trust. When the group chooses your solution, and chances are they will, then they’ll trust it because they chose it and that reflects their trust in you and the process. If they don’t choose it, but you have done a good job, then they’ll trust you and come back another time when they’re ready for what you have to offer. They’ll also advocate you to others.
Move one step at a time – Move through each step slowly. The time it takes to move through a step is the time it takes to move through a step. There is no sense in hurrying the process, as doing that will not lead to better results or faster agreements. It will, in all likelihood, move towards shallow agreements that don’t stick and ill-thought-out solutions that don’t properly address the problem. The time it takes to move through a step will also give you a good indication of the time you’ll need for the steps to come. Be prepared to adjust your timelines if necessary, and to return to earlier unresolved issues if need be.
Ask many questions, get clarifying answers, ask dumb questions, the dumber the better – Try not to ask leading questions. Keep asking questions until you get clear, simple answers. Break down compound answers, where necessary, into fragments and drill down until you have the clarity you need. Dumb questions are often the most valuable questions. Asking a dumb question often unpacks important issues or reveals hidden and unchallenged assumptions. It’s very surprising how fundamental some of these assumptions can be, so be brave on this point.
Reduce, reduce, reduce – The clearest points are simple ones.
Get agreements as you go – Double check that everyone is on the same page as you go. Get explicit agreement, even on seemingly obvious points. Total consensus is not always necessary or possible, but general agreement is.
Document it all – Get it down in simple terms on whiteboards or using whatever tools you have available. At the end of sessions, commit what you’ve documented to digital, shareable media.
Summarise your journey and where you are now – At the end of a session, it’s always necessary to summarise in clear terms the journey you have taken and the point at which you’ve arrived. Get consensus on this. It’s also useful at various points throughout the session to do this as a way of 1) illustrating you’re all on the same journey, and 2) reminding people what the session is all about. In the summary, make sure to illustrate that you understand the key points. Bring out points that may have taken a while to get clarity on or that you may have initially misunderstood. There will be many of those points if you’re doing your job well! Doing that lets the group know you’re embedded with them and not merely guiding them towards your own predesigned end game.
Use their semantics – Use the group’s terminology to describe the problem and the solution. Don’t impose your own semantics. Remember, they are the experts. Use their language. If, instead, you use your terms in the process then inevitably people will become confused. If a term doesn’t exist for something, ask them to define it.
Remember, facilitation is an art of invention – At the very least, facilitation is an act of translating known patterns into a new context and tweaking those patterns to fit that context. But the reality is that much of the what a facilitator does involves making things up. Instinct and the fear of failure force the on-the-fly invention of methods, but a good facilitator makes it appear that the method has existed for a hundred years and has never been known to fail. When it does fail, a really good facilitator will ensure that no one notices and that the outcomes were the ones you were after.
I’m in New Zealand for a few weeks so I’m working and enjoying the summer. Good thing is that the timezones overlap perfectly so I can be in touch with San Francisco in the morning, and in the evening work with the team members in Europe. In between I either work on a book about the design methodology (the Cabbage Tree Method) or go surfing! Perfect!
I’m a pretty bad surfer but its heaps of fun.
Recently I have had two streams of negative energy focused on me by others. One was a troll that wished to damage my reputation, and the other has (recently) been negative comments made in response to a post I wrote about diversity in open source.
I think I am getting better in handling this kind of attention. Spending time to consider the issues and the negative responses has, interestingly, led me to reflect on and, consequently, to strengthen my position. Hence in some ways my response has been ‘unequal and opposite’ to the negative energy. Instead of hurting me, as this kind of negative strategy intends, it has helped me to learn a lot about what I am doing and why, and to commit to my position more energetically in a way which is positive in both response and result.
I might actually be growing up. Gasp! (not without the help and patience of many wise friends 🙂
I’ve been thinking about Open Source and diversity. It is true that open source, in my experience, is largely populated by white men who can program. I think this would come as no surprise to most people reading this post. However, I have been stimulated to think about it a little more due to some very odd reactions on an email list I am subscribed to when I, very gently, pointed this out. The reactions to my comments were extremely negative and very personal. Over the last few weeks, in reaction to points I have made on the list (related to diversity and possible new models for open source projects), I have been accused of racism, questioned about my nationality, asked if I speak English, made fun of, and it has been suggested many times that the kind of work I am doing is fruitless.
I find these points say a whole lot more about the persons making them and the associated dominant power dynamic than anything else. Never-the-less, as a result of these comments, I have been prompted to reflect on, and refine, my position regarding diversity in open source.
Essentially, I see the lack of diversity as a problem on so many levels. I am disappointed, on a human level, that there isn’t a greater diversity of ethnicity, and gender, involved in open source projects. I also lament the lack of role and skill diversity in open source projects. I believe this lack of diversity hurts us as humans and hurts the effectiveness of open source. I wish to see a greater diversity in open source.
I am a white male and I am part of the dominant power demographic. I don’t feel guilty for being so, but I do believe, as someone that is part of the dominant power group, that I have a responsibility to address the imbalance. So, if I wish to see greater diversity in open source, then I should do something about it.
After pondering what I can do, I have come to two points, and they reflect how I see the yin/yang personal – political nature of this issue:
In a way, there is nothing new here. But I needed to think this through a little to work out my own position regarding the issue of diversity. How I can better achieve the actions above is something I will need to work on (continually). I’ll ponder it more, and I welcome any thoughts you might have on the issue that can help me on my way.
After posting the possible introduction chapter to a book on the Cabbage Tree Method to a list full of Open Source luminaries, I got some great feedback, but I was also ridiculed by some and called racist by a couple of others. The racism allegation was in response to my statement that in open source I have observed “the dominant power being held by white men who know how to code.”
Amazing the reactions you get from pointing out the obvious and very lightly advocating a reasoned alternative to the current models of open source projects.
So, I’m reading a little about diversity in Open Source. Some great materials I am currently pondering include:
Open Source Is Way Whiter And Maler Than Proprietary Software
Self-censorship in tech and social change
When it comes to diversity, what does success look like
You will note from the first link that there is some suggestion that women, for example, constitute only 1.5% (max 10%, its unclear) of open source project contributors.