Coko loves the transparency and sharing that are the hallmarks of open source. However Open Source is not just about plunking your code down for all to see, it is about collaboration – working with people to develop products.
Coko is developing a best practice framework, a collaborative methodology if you will, for developing successful user-facing products. There are many similar Systems Development Life Cycle methodologies such as Extreme Programming, Radical Application Development (RAD) and Joint Application Design (JAD) which are employed by software development houses and other organisations to build products. However none of these really make sense for open source product development although there are bits of wisdom we can reuse from many of them.
For the time being Coko is hanging the title ‘Collaborative Product Development’ on this emerging methodology. The idea is still fresh but it is apparent that the following are some of the critical ingredients:
- Diversity of stakeholders
- Product flexibility
Diversity creates better projects. So, why aren’t designers participating in open source? – Una Kravets
Diversity of input makes for better products. This is not a new idea in the world of product development, since Ikujiro Nonaka wrote about the ‘new new product development game’ in the 1980s and the inclusion of a diverse set of stakeholders has been considered critical to product development. Interestingly this kind of diversity has been strangely absent from the open source sector.
Hence Coko intends to develop a different kind of culture from your typical open source project – a culture that shifts away from technocratic meritocracy and towards a community of diverse stakeholders. This means including all stakeholders in the process – users, strategic organisational and sector champions, graphic designers, user experience designers, developers and others that are affected by the solution.
Involving a wide range of people with differing perspectives improves products but collaboration of this kind doesn’t ‘just happen’ hence the importance of our next ingredient – facilitation.
Leaders need to cede control, not vigorously exert it. – John Abele
As John Abele, founder of Boston Scientific, found when introducing revolutionary new surgical instruments to a hostile market, collaboration not only improved the product but “really accelerated the development of these new technologies”.
Creating successful collaboration is a product of a particular kind of leadership – what John Abele calls ‘collaborative leadership’. Ikujiro Nonaka calls this phronetic leadership and asserts that “A phronetic leader mobilizes timely judgment in others by building a culture that is strong, nurturing, and sustained by informal connections.” And John Abele goes so far as to provide something of a list of attributes including:
- 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”
Coko is using the term ‘facilitation’ to refer to this kind of leadership and we intend to work a lot with these principles when facilitating collaborative design processes.
innovation diffuses more rapidly when it can be re-invented – Everett Rogers
If you bring people together to improve a product it stands to reason the product should be easy to improve. Hence Coko is building very flexible products that can be ‘re-invented’ by those that need them. Afterall, if you can’t improve the product there is little use in bringing people together to do so.
As it happens, Product Flexibility is also considered by many diffusion theorists to be a key asset in fueling product adoption. The greater the ability for a product to be adapted the greater the chance it will be used. Rogers and others suggest that if the tool can change to do what you need, it will more more successful for you, and you will then transmit the success of its implementation to others – fueling their interest and (hopefully) eventual uptake. Hence Product Flexibility is not only good for the ongoing health of the product, allowing collaborative design processes that can easily improve it, but it also potentially lays the groundwork for a healthy and accelerated adoption cycle.
Diversity, Facilitation, and Product Flexibility are the cornerstone ideas for an emergent Collaborative Product Development ‘methodology’ Coko is thinking through. It is interesting to note that you can talk about these concepts and how they can improve a product and its adoption without actually talking about the underlying technology at all. This is not to say that the code is not important, but it highlights the fact that a healthy Open Source community that produces excellent products is not only about the transparency of the code. A mistake that is all too commonly made by tech-centric open source projects. We intend to expand this conversation and budge open the (sometimes stubborn) doors to critiquing and improving the way open source products are produced. If you would like to join this effort please jump into our live chat and say so! (https://mattermost.coko.foundation).
Post by Adam Hyde, improvements by Kristen Ratan