Wax Show ‘n’ Tell
Hindawi Limited & Coko Announce Partnership
Coko & eLife partner on first PubSweet fueled journals submission & peer-review platform
Seeding a New Ecosystem: open infrastructure
Take Editoria for a spin
Making decisions in a small team and keeping it fun
A look at the future of journals with xpub
Editoria 1.1: Meet the Automagic Book Builder
A sneak peak at what’s next for PubSweet
Travel the long and winding road to PubSweet
Ink 1.0 is here!
Baby steps to user-centric open source development
Why we’re all in open source now
Getting Started with Coko
Editoria 1.0 preview
Preprints won’t just publish themselves: Why we need centralized services for preprints
INK – the file conversion engine
How we’re building the ‘mountain chalet’ of complex conversions
Sowing the seeds for change in scholarly publishing
Open Source Alliance for Open Science
Editoria Newsletter Out Now!
INK client upgrade
All About INK (explained with cake)
Track Changes (Request for Comments)
Book on Open Source Product Development Method Released!
Italics, Buenos Aires and Coko?
Editoria Update
Where we are with File Conversion
A Typescript for the Web
Coko Celebrates Year One
Editoria – Scholarly Monograph Platform
Adam Hyde’s Blog
Introducing Christos
Introducing Yannis
New PubSweet release
Attribution in Open Source Projects
Open Source for Open Access
Reimagining Preprints: a new generation of early sharing
Introducing Stencila and Nokome Bentley
Reimagining Publishing
Introducing Charlie
PubSweet 1.0 “Science Blogger” alpha 2
PubSweet 1.0 “Science Blogger” alpha, INK 1.0 alpha RELEASES!!!
Collaborative Product Development
Publishing for reproducibility: collaborative input and networked output
Substance Consortium
UCP & CDL Announcement
Release 0.2.0 is here!
CKF receives funding from the Gordon and Betty Moore Foundation to transform research communication
Technology Slows Down Science
[tech post] CSS and Drop Caps
Vote for the pubsweet logo!
Introducing Substance
Digging Collaboration and Cooperation: Code for a New Era
Coko 2015
PubSweet 0.1 Release
Coko Resources
Making science writing smarter
What I Have Learned About Building Community
Introducing the Tech Team
Knowledge and Communication
PKP and CKF Strategic Alliance
CKF Launches
May 24, 2016

Collaborative Product Development

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
  • Facilitation
  • Product flexibility
  • Diversity

    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.

    Product Flexibility

    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! (

    Post by Adam Hyde, improvements by Kristen Ratan