Examples of sector change
Community building begins with convincing people who don’t need to work together that they should.
– John Abele
Recently I have found some clues to these questions in the writings of John Abele (founder of Boston Scientific), particularly “[Bringing Minds Together]”(https://hbr.org/2011/07/bringing-minds-together). His writings have inspired me to look again at how I see Open Source.
Early in his career, John was involved with some technologies for non-invasive surgery. Today, such matters are handled day-to-day. 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.
So he had a hard time trying to sell a new idea that he knew could transform the medical sector. 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 behaviour. … 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.”
That’s more-or-less what we face with Coko (Collaborative Knowledge Foundation) at the moment. Smart people that are under the painful burden of outdated workflows and technology often resist systemic change because it requires them to alter their normal ways of working. Their resistance to change is a huge problem if you wish to modernise the way knowledge is produced and reduce that burden on them.
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 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.”
That sounds like an odd sales pitch now, but 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 shaped the product. They became 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 this was 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 you could have told the same story about any number of successful Open Source projects. Indeed, John reflects on the parallels to Open Source :
“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 both cases started with a simple idea – to create a community of change agents.
Leadership
Leaders need to cede control, not vigorously exert it.
– John Abele
The creation of a community where collaboration can flourish is a product of a particular kind of leadership – what John calls ‘collaborative leadership’. I have also seen this in many places including Open Source, Unconferences, and Book Sprints (which I founded). In the latter two cases, we call the collaborative leader a facilitator.
There are many modes of facilitation and choosing the right characteristics, the right mode, to create the right environment, is critical. John gives some interesting tips on what this mode looks like. The characteristics that I have gleaned from his article include the ability to:
- foster “collaboration among people who had previously seen no need to work together”
- manage egos
- earn trust
- respect stakeholder interests
- be authentic
- “listen, share, and ask good questions”
- share the credit
- use “we” not “I”
- support the choice of ‘alternative methods’
- create rituals
- create non-traditional spaces and experiences to come together
- ensure people “feel like partners”
- be willing to take direction from the ‘customer-participants’
- build trust over control
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
A good facilitator knows this language and these modes and can apply them but there are different requirements for facilitation depending on what you are trying to achieve. Book Sprint facilitation, for example, is much more product- orientated (books) than Unconference facilitation and requires a different set of strategies and tools. Most of the issues above I would categorise as being general rules of facilitation, however, those that modes that hint at enabling a group to create llarge-scalechange are the most interesting here. I think the last four points are telling:
- be willing to take direction from the ‘customer-participants’
- build trust over control
- “point out the deficiencies in the tools” you are making
- present ideas “in ways that [cry] out for input”
The most important issue at stake here is for the facilitator to create the space so others will come up with the product solution. This kind of facilitation creates vacuums, spaces where solutions don’t yet exist. This kind of facilitation is focused on a diverse range of stakeholders to design the product. This kind of facilitator doesn’t have all the answers but instead highlights problems and brings people together to create the solutions. Typical facilitation modes are necessary to enable an environment of trust and sharing, but enabling the participants to own the problems and create the productized solution requires a very specific mode of facilitation.
Can Open Source do this?
Open source software is about people.
– Sacha Greif
While these examples are about proprietary technology. It is not the proprietary-ness at stake here, it is the process that is important – and good process is the product of good facilitation. Often there is facilitation active in Open Source projects, but not necessarily, and where it does exist it is not typically with the kind of framing John has pioneered. Sure projects want people to use their software, they want to be sustainable, they don’t want to do all the work, they want community. However, Open Source projects are typically interested in bringing in more developers and not necessarily on fueling wide scale adoption (as odd as that may sound), and this informs the kind of people involved and the facilitation strategy employed.
There is a great article by Telescope founder Sacha Greif that illustrates this quite well. Sacha writes – “So why did I decide to make Telescope open source in the first place? It’d be easy to answer with typical clichés about “giving back to the community” or “believing in free software”….But the truth is a lot more pragmatic and selfish: I thought it would be a good way to get other people to help me accomplish my own goals, for free.”
Sacha goes on something of a journey with Telescope, undertaking some course corrections, and concludes “when it comes to Open Source software, software actually plays a fairly minor role. Open Source software is about people.”
I think this illustrates quite nicely where the mindset of open source projects generally are. Sacha went past the ideal of ‘build it and they will come’, a very tech-centric way of seeing things, through to understanding that the secret to success for an Open Source project lies with people, not technology. Sacha transitioned from developer to facilitator.
That is very laudable. However, facilitating developers to build your technology, is very different from facilitating a diverse set of stakeholders to develop a product, fuel adoption, changing user behaviors and putting your project on the path to creating wide scale change. The later requires involving different stakeholders and it involves a different mode of facilitation.
This is where Open Source is getting in its own way. Open source is about employing the right tools, facilitation included, to expand your developer base. That’s fine if you are building the plumbing – Open Source libraries, under-the- hood services, backend functionality etc can all be built well using this kind of method. However, if you want to be part of a team that creates wide scale change through a user-facing product, then I would suggest that open source as a culture-methodology is not the way to do it. Open Source is, at its heart, a techno-meritocratic culture. Great for building under- the-hood tools (builders building for other builders), terrible for producing products.
This shouldn’t be surprising. Somehow, however, it is. But then again when we look closely it sort of makes sense…Even the term ‘Open Source’ expresses just how much the code and those that make it form the core orientation and value metrics. Additionally, in a typical Open Source project, the person at the top isthe person with all, or most of, the technical answers (in a techno-meritocratic culture you can only not know so much before you ain’t the boss anymore). The famed benevolent dictator. And they are the culture keepers, the arbitrators, the facilitators. This sets the scene for a particular kind of facilitation that privileges the involvement of those with technical skills over anyone else. This all points to a certain kind of mono-cultural community.
To see a good example of this have a look at this post about Octocat. The entire emphasis of this article is to find ways to celebrate ‘non-code’ contributions. The term ‘non-code’ in itself is an indicator that anything other than code only has value by association (imagine a manager in any industry thanking a group of workers for their ‘non-management contributions’). Octocat was developed to measure ‘non-code contributions’ and to be effective ‘non-coders’ must log their activities in the projects issue tracker. Hence all contributors must use the same tools that the developers use. Octocat is a good project but it highlights just how focused the entire culture of Open Source is on technical development and needs everyone to fit into that paradigm. I believe this is at the cost of the product, adoption, and the potential change the product could make if managed differently.
Diversity
“Diversity creates better projects. So, why aren’t designers participating in open source?” – Una Kravets
So, what must open source change to enable a project to create massive change? Open source requires a different kind of culture. Open source must diversify away from technocratic meritocracy to become diverse communities of stakeholders. Unfortunately just the opposite is happening – ‘non-coders’ are being chased away in droves.
This is not new news. Open source has sort of known there was something wrong with its culture for sometime. The wholesale migration to closed source desktops (Apple) by the open source development world highlights this. Why did we see this enormous migration? Because OSX is ‘nicer to use’. That tells us something. Open Source has generally failed on user experience (I must note that I do not believe that to be the case now for open source desktops) and it has failed because Open Source culture is not inclusive of designers. The mono-culture has very firm boundaries for what it can do well, and it cannot provide good UX unless it diversifies.
Una Kravets has done a very nice presentation about these issues. In this presentation Una goes into detail of why designers are not involved in open source and how to enable the conditions to improve participation.
The point here is that it is not just a question about representation (and the shockingly low numbers of women involved), it is also a question of the health of a product. As Una has argued well ‘diversity creates better projects’. I would like to take that one step further and suggest that diversity not only creates better projects, it creates better conditions for wide scale adoption and change. To develop a successful product you need to have the customers designing the solution, you need UX designers to finesse the interactions, designers to make it look great, evangelists to present it at conferences, you need developers to do the plumbing, you need users for the feedback, and you need facilitators that can bring all these people together and enable them to function as a passionate, problem-solving, engaged whole. To do that, all those people need to be drawn from a diversity of contexts, valued equally, and they must all have a say in what it is that is being created. You need what John Abele calls ‘a community of change agents,’ not a community of developers.
Involving and privileging only developers is not the right kind of culture to achieve success with a product. We must do away with the techno-meritocratic culture of Open Source and replace it with a more change-centric paradigm – the community of change agents. The root of this new kind of product development culture requires a specific kind of facilitation (‘collaborative leadership’), and the passionate involvement of a diverse set of stakeholders.
The writings of John Abele have led me through a curious journey. While I was always troubled by the technocratic nature of Open Source, I figured it was a transformational movement and I would figure out a way to exist within in it and assist where I could. However, I am now seeing very clearly that, while there are individual exceptions, Open Source as a movement has its own hard coded limits. Unfortunately, these are limits that stunt effectiveness and the ability to create wide scale change, especially with the user-facing products. Unfortunately, the Open Source movement itself is barely cognizant of these limitations, why they exist, and how they could be removed.
Coda for the trolls
It probably won’t help moderate your responses but just in case… a bit of a background of where I am coming from. I love Open Source, I think it has done amazing things. I am a free license and free culture advocate. I started communities of free documentation writers to support Open Source, have initiated many software projects – all Open Source – and contributed in humble ways to others. The Open Source projects I work in now use entirely open source tools. I have supported free culture campaigns with my own time and money including (most recently) The Cost of Freedom. I have lived and breathed Open Source for about the last 20 years. I haven’t used any other desktop since 2000 or so, and have belonged to, and worked with, many hacker collectives. I don’t intend to give up on Open Source any day soon, but I do intend to do what I can to make it better, however small that contribution might be.
*original article and history here https://www.adamhyde.net/open-source-is-not-about-people-or-technology-its-about-change/ *
With thanks to Andrew Rens for great feedback, and Steve Song for some inspiring asides.
