Ten Years of Coko(!)

I saw a post on LinkedIn recently—someone congratulating me on my 10-year anniversary at Coko. I hadn’t realized it had been that long, but they’re right. It’s been a decade.

Coko started in 2015 with seed funding from my Shuttleworth Foundation Fellowship. The first person I hired with the Shuttleworth funds was Jure Triglav, who remains a close friend to this day.

We began with a bold but simple idea: what if, instead of building one-off publishing platforms over and over again, we built a framework for building publishing platforms—something component-based and reusable?

It seemed far-fetched to many at the time, but we were convinced. I had already built several publishing platforms and learned that each time, the next one was better. So why not embrace that iteration? Why not create something that made it easier to build and let go of platforms—to build, learn, and build again? While building this technical framework - originally PubSweet, which later evolved into CokoServer - became a central focus, it was just one part of a broader vision. I also set out to shape a culture and set of goals that would define Coko’s identity from the start.

From the very beginning, we also pushed hard for HTML-first, single-source publishing systems. Our position was simple: XML—the traditional format in scholarly publishing—is unnecessarily expensive, overly complex, and imposes rigid, linear workflows. It creates a split in the process: before XML and after XML. This bifurcation limits flexibility, makes collaboration difficult, and excludes non-technical contributors from the editing process.

This insight came directly from my earlier work developing the Book Sprints methodology, well before Coko. In Book Sprints, we demonstrated that collaboration is essential to achieving outsized productivity gains—but not just any collaboration. What made Book Sprints work was synchronous, concurrent collaboration, where everyone works on the same content at the same time. This level of concurrency was only possible because we chose HTML as the underlying format.

Using this approach, we were able to produce books from scratch—zero to published—in five days or less. Many of these were published by major houses, and the results consistently proved the point: HTML enabled concurrency; concurrency enabled true collaboration; and collaboration delivered unprecedented speed and quality.

HTML enables parallel, collaborative workflows. It supports multiple tools and roles working concurrently on the same source. It’s also far cheaper and faster to build usable GUI tools on top of HTML than XML. And let’s face it—almost all of the world’s knowledge is either published natively in HTML or converted to it for discovery and consumption. So why does the publishing industry cling to XML like a snowflake, insisting on its uniqueness?

This vision wasn’t just something we talked about before Coko—it became deeply embedded in the DNA of everything we built. And over time, many other systems have followed the same path. We’ve now demonstrated that collaboration and concurrency are key to reducing time and cost in publishing, and that HTML is the foundation to make that possible. In short, we, and time, has proved our point.

Just as we championed HTML-first, we were equally committed to collaborative technical development. From the start, we believed that too many publishers were building more or less the same thing, over and over again. How much money has been wasted on this fruitless exercise? Especially when many of these systems either fail entirely or, if they succeed, become expensive legacy burdens. The real cost sometimes isn’t just in the initial build (which may fail to get to production) —it’s in the long-term maintenance of bespoke, siloed infrastructure. It’s madness.

We’ve always argued that collaboration is not only more efficient—it’s smarter. It reduces duplication of effort, increases the likelihood of success, and creates opportunities to learn from a wider range of perspectives. By working together, teams can share both their breakthroughs and their mistakes. That’s how real progress is made.

At the time, for example, many believed building a journal platform was practically impossible. A few early players had cracked the code, and everyone else seemed to fail. These failures were often framed as technical or production shortcomings. And it’s true—many attempts didn’t succeed. I designed and built one of those high-profile failures myself: Aperta for PLOS. But there were plenty of others that never made it either.

Over time, this narrative started to feel like a convenient myth—one that protected incumbents and discouraged newcomers.

From my perspective, having failed firsthand, the real problem wasn’t technical. It was the lack of shared knowledge in the industry. No one was talking openly about what worked and what didn’t. Failures happened silently inhouse and no lessons were learned by the wider industry. That’s why I came to believe that collaboration is the key to not failing. Sharing lessons, strategies, and systems is what gives new efforts a real shot at success.

As a consequence, over the last ten years, we’ve built multiple platforms in collaboration with a wide variety of partners. For a small organization, the volume and quality of what we’ve produced is exceptional. And given how many proprietary or closed systems have failed in that same timeframe, we believe we’ve made a strong case: collaboration works—not just as a nice ideal, but as a practical strategy for building better, more sustainable publishing infrastructure.

We’ve also been unwavering in our commitment to 100% open source. But let’s be clear—open source is easy to get wrong. From day one, we believed it should be liberally licensed, with no proprietary dependencies that prevent someone from deploying the application end-to-end without paying for a closed component. That’s why we built our own open-source typesetting engines and avoided vendor lock-in at every step.

We also rejected the fear of the so-called “free rider” problem. In our view, anyone should be able to use the software—for any purpose—whether they contribute back or not. That’s the cost of true openness, and it’s worth it.

But more importantly: you simply cannot collaborate with multiple organisations effectively without a shared codebase. I can’t even imagine what we’ve done over the last decade if it had involved pages of NDAs, licensing agreements, and gated access. That kind of red tape would have killed the spirit and speed of collaboration.

Open source is the most frictionless, productive, and good-faith environment for building things that matter—especially in publishing, where the problems are systemic and no single actor can solve them alone.

We launched the idea of Coko and PubSweet at an event in San Francisco. There were a few raised eyebrows in the room. But we started anyway. We brought in early collaborators like Michael Aufreiter and Oliver Buchtala from Substance and began designing what would become PubSweet, the original Coko framework.

PubSweet was the cornerstone of everything we built at Coko. It gave us the flexibility to build, rebuild, and collaborate—and crucially, to embed our broader goals, like HTML-first workflows and concurrent collaboration, into an open-source, collaboration-ready technical framework. It was later rebuilt by Yannis Barlas and refined into what we now call CokoServer.

We quickly realized we needed collaboration from broader use cases to design something truly reusable, so we started talking to a wide range of folks. Some of these chats worked. I remember sharing coffee with Andrew Smeall from Hindawi about this on the bench outside Monmouth in London. Then later a chat at a conference with Paul Shannon from eLife, and later Audrey Hamelers from EMBL-EBI. Together, we formed early partnerships and began designing real systems.

This group of partners—Coko, EBI, eLife, and Hindawi—met regularly in person, often around the UK, to design and build PubSweet together and to learn from one another. Meetings brought together around 30 people (sometimes more), with entire development teams working side by side for two or three days at a time. That closeness and camaraderie carried over into our remote collaboration, helping sustain momentum between gatherings.

The team at Coko also grew. I met Yannis Barlas in the back of a taxi in Athens on the way to a mutual friend’s wedding. He later joined the team, along with his friend Christos and Yannis Kopanas—all of whom are still involved today.

Both the PubSweet collaboration and Coko built a lot of successful products. The PubSweet Collaboration helped build:

• EPMC+ with EBI (still in use)
• Phenom with Hindawi (later acquired by Wiley and still in use)
• eLife’s first iteration of Libero components (since deprecated)

The Coko team also built:

• Editoria, our book production platform with CDL and the Mellon Foundation (since rebuilt as Ketty and thriving)
• Kotahi, our journal platform (slowly developed since 2020, now thriving)
• Micropubs for Caltech (still in use)
• Biointeractive Assessment Builder for HHMI (in active use)
• A partially built platform for NCBI (we lost the final bid but learned a lot)
• The DataCite Citation Corpus platform (in active use)

At some point, Digital Science also built a very interesting re-composable workflow platform on top of PubSweet. There were others too, though I can’t recall all the names (!). The Digital Science app stood out because it allowed users to design workflows visually - using a kind of diagrammatic interface - and then compile those workflows into fully functional publishing platforms (similar to what I think the PubPub Platfrom was trying to achieve).

Along the way, we identified gaps in publishing infrastructure and built components to fill them:

• A document conversion engine (INK, led by Charlie Ablett, then later XSweet)
• A web-based word processor (Wax)
• And later, typesetting tools via Paged.js

Paged.js deserves a special mention. Although not technically a Coko project, I used Shuttleworth funding to launch it as a standalone project with Fred Chasen and Julien Taquet. It was built as a standards-compliant open-source pagination engine—one that’s now used everywhere, including by the Louvre to produce exhibition catalogues.

In terms of adoption, Pagedjs is one of the most successful products I started.

Of course, not everything in our tech journey went smoothly or turned out to be a success. We invested a significant amount of time, energy, and funding into a Substance.js-based word processor through the Texture consortium (which we played a critical role in founding) - which ultimately failed. While the project’s founders were initially aligned with our vision, they eventually steered it in a technical direction we felt was fundamentally flawed. This wasn’t a minor disagreement; the approach they pursued reinforced the very XML-first paradigm we were committed to moving away from.

Letting Substance go was a difficult decision. I vividly remember spending three intense days in Athens with the development team, agonizing over our options. In the end, we chose to part ways with Substance and rebuild using ProseMirror. It was a tough call, but ultimately the right one. Others made the same move—Stencila among them—when the Substance/Texture approach failed and eventually disappeared.

Despite the occasional setback (and there weren’t many like this), technical development at Coko has always been about making smart bets. We adopted Node.js and React at a time when their future in the open-source world was far from certain. Today, they’re foundational technologies—but back then, that was anything but obvious. We also embraced GraphQL early. Most of those bets paid off. A few didn’t. That’s the cost of building at the edge.

We also placed bets on people. And that’s where we’ve been most successful. Many folks who joined Coko at the start are still with us—either directly or as collaborators in the broader ecosystem. I'm still in touch with nearly everyone who passed through Coko. We share a kind, committed way of working that I’m proud of.

We also tried to build not just platforms, but reusable components. That part has been harder. There’s a strong “not built here” culture in publishing—even in open source. Still, tools like Wax and Paged.js have found homes far beyond Coko, and that’s encouraging.

There have been many other varied projects too. During COVID, we launched the Open Publishing Awards and Open Publishing Fest—two of the projects I’m most proud of. The Fest, in particular, was designed to be remote-native, not just a digital copy of a physical event. It brought people together during a hard time and showed what distributed, asynchronous collaboration could look like.

Following up from that we co-organised the PageBreak conference with Peter Brantley, Andrew Savikas, John Chodacki, and Nellie McKesson - a follow up to the amazing Books in Browsers.

In addition to building technology, we also built processes—arguably the heart of what Coko has always been about: Community, Technology, and Process. From the beginning, we invested in designing processes that support strong communities around our key projects—Editoria, Ketty, Kotahi, Paged.js, and PubSweet.

I also developed a methodology to help organizations better understand their publishing workflows and map those to technology. It’s called Workflow Sprints, and it builds on the Book Sprints method I created years earlier.

A Workflow Sprint is a rapid, facilitative process I developed to help teams deeply understand, streamline, and improve their publishing workflows—before jumping into technology. It brings together operational staff (those doing the day-to-day work) and strategic stakeholders in focused 1-day in-person sessions or multi-part remote workshops. As the facilitator, I guide the group through mapping their current workflows, identifying inefficiencies (“eddies”), and collaboratively designing a more efficient alternative. The entire process takes days—not months—and results in clear, human-readable workflow diagrams that provide a strong foundation for smart, informed technology decisions.

We did a lot of Workflow Sprints and with each I learned a tremendous amount.

We had a lot of people work at and with Coko. Coko, as all best not-for-profits, was laregly sustainable becase we could scale like an accordian. Sometimes up, sometimes down. Since 2019 in particular we grew significantly. In 2020-2023 we were at about 40 people.

Since 2015 we have done a lot but most important is that our key platforms are now mature and sustainable. Kotahi in particular is well on its way to becoming a standalone non-for-profit 501(c)(3) foundation with it's own invested stakeholders, and Ketty is progressing on a similar path.

What’s really worth noting is that any one of these projects would—and often does—represent the full output of an entire organization. There are companies that have spent years building just a journal platform, or just a typesetting engine, or just a word processor, or just a framework. We did all of that—and more. We created projects that, on their own, could have been the flagship achievement of an organization dedicated solely to that one task. That’s something I’ve always found difficult to fully convey or quantify.

And while it’s been rewarding, it’s also often been a grind. Doing this many projects has required continuous innovation—both technically and organizationally. We've faced countless challenges, not least financial. To have succeeded in building even one of these platforms—and made it sustainable—would be a major accomplishment. That we’ve done it multiple times is something I’m deeply proud of.

But those lessons deserve their own space—a more reflective post, still to come.

To recent times - we’ve also taken AI very seriously and deep dived into it. We deeply integrated AI into many platforms we built. We built an AI Designer (actuallym multiple takes on an AI designer), a RAG knowledge base, and an AI Assistant. I’ve also launched Vibe Coding workshops and am prototyping like crazy eg https://easyjournal.org/, https://v2.easyjournal.org/ and https://designer.nikau.consulting/.

There are many people to thank. My thanks here to some key folks who have been instrumental along the way, many of which have become close friends. John Chodacki has always been a strong contributor to Coko’s direction, offering steady guidance and insight. Paul Shannon has been deeply involved since the early days—not just collaborating, but actively shaping how and what we build. Andrew Smeall has also stayed involved as an advisor and sounding board. Yannis, Giannis, and Christos have been with Coko since the beginning, and are among the warmest, most grounded developers you’ll ever meet.

Jure Triglav, a longtime friend and former colleague from our days at PLOS, was instrumental in making PubSweet possible. His early contributions were foundational to its evolution and success.

Sidorela Uku and Bela Toci have been key for our QA efforts. Charlie Ablett, now at GitLab, has long been both a trusted sounding board and a valued team member. Julien Taquet played the role of a much-needed jack-of-all-trades. Allen Gunn from Aspiration helped guide Coko through both smooth and rough waters. Alison McGonagle-O’Connell brought tremendous energy and vision to developing the early Editoria community and also helped Coko with networks and marketing more generally. Agathe Baëz and Henrik van Leeuwen are the amazing folks behind all of Coko's design. Bethany Lyons was amazing helping with admin throughout the COVID years later to be succeeded by Feli von Peter who I work with now.

Grigor Malo (now Ketty lead) and Vukile Langa (now Kotahi lead) have been awesome collaborators, working on many of the big Coko platforms and still working on them today. Wendell Piez was critical for our HTML-first philosophy as the designer of XSweet. Alexis Georgantas was great to work with as the lead developer of Editoria. Mathias Romeo who has been my closest collaborator on our AI explorations.

Thanks also to the Shuttleworth Foundation, (all the fellows but in particular, Helen King-Turvey and Karien Bezuidenhout) which helped incubate Coko indirectly through its unique peer-to-peer mentoring model, and to Fred Chasen, who has been with Paged.js from the start and brings a rare depth of technical experience. Julie Blanc was also very important for the foundational years of Pagedjs. Dione Mentis played a critical role as we stewarded Coko through rapid growth during COVID.

Coko had many contributors pass through its doors over the years, especially in the early days. While some played more visible roles at particular moments, the real story of Coko is one of collective effort—built by a wide range of collaborators, partners, and team members. That said, the vision and execution described here reflect the direction I personally led and nurtured throughout the life of the organization.

As for Coko… it’s probably time to start slowly and gently putting it to bed. The projects have legs of their own now. Kotahi, Ketty and Paged.js in particuarly are looking strong. They will continue and grow. I'll stay involved in all of them. But I’m also starting to focus more on building platforms for others, consulting, and carving out new experiments.

There’s a new project in the works ('PS') —AI-focused, of course—that I’ll be announcing soon.

It’s been an amazing journey. We proved a lot of people wrong, took mostly the right risks, and, most importantly, built good software and even better friendships. I’m proud of both.

Here’s to the next chapter.

—Adam