The shift from single-player to multi-player in software can also be described as the rise of real-time collaborative tech.
This wave has swept across many industries, especially those that struggle with high fragmentation and multiple stakeholders who own siloed parts of the value-creation process. It’s not just the gaming, design, and “productivity” (note-taking, screen-sharing, meeting, project management, etc.) industries that have been revolutionized by adopting the multi-player technology, though.
Many SaaS businesses, even companies that haven’t traditionally thought of themselves as collaboration-first, are now deciding to adopt multi-player features in their applications.
Today, we all agree that collaboration in the workplace is a must. This is particularly evident in software development, which is an intrinsically collaborative process involving teams of developers working in their own remote, persistent environments, constantly interacting with one another.
So, how did we get to the point where internet-based, collaborative development tools are a must?
Setting the stage
It’s not a coincidence that collaboration software was the only software segment that posted positive (6%) growth during the onset of COVID-19 and the market size is expected to expand at a compound annual growth rate of 9.5% from 2022 to 2030.
Here are three macro trends to keep in mind, which have shaped the tech industry and made multi-player functionality necessary.
- Shift towards distributed systems — Distributed architecture represents a paradigm shift in the design and deployment of computer systems. It fosters a decentralized approach to computing for enhanced scalability, fault tolerance, and performance. This is particularly crucial in the era of cloud computing and large-scale data processing, where the demand for scalable and resilient systems has become paramount. In a way, we’re all distributed system engineers now.
- Shift from in-person collaboration to online collaboration — Collaboration is becoming more and more web-based (think of the online tools for meetings, document creation/editing, design, customer support, etc.). There has also been a multi-decade global shift from physical to digital spaces, which was massively accelerated by COVID-19. Even with the current RTO mandates, globally distributed engineering teams still need to collaborate across offices and timezone!
- Shift to browser-based applications — Browser-based applications are having a moment — just think of all the software startups, that raised significant venture capital funding in the past few years (e.g. Lucid, Figma, Sourcegraph, Replit, etc.) and of the top performing apps in 2022 (Figma, Sentry, Miro, Hubspot, Asana, Github, etc.). What’s important to notice is that most (if not all) of the collaboration and productivity tools are architected with multi-player functionality at their core. That’s because modern users intuitively understand that Internet native software should embody values like collaboration, transparency, and access.
Welcome Player Two: Benefits for developer tools
With the increase in remote engineering teams, the beauty of simply opening a project and seeing the same version auto-updated (including everyone’s comments, dependencies, code changes, and workflows) becomes significant. But let’s dive a little deeper:
- Better developer experience (= quicker time to fun): In the developer world, all areas that don’t contribute to the creative output and the delivery of applications should be simplified. In this context ensuring that developers can align, communicate and drive consensus in a straightforward, timely, and collaborative way is crucial to reduce overhead, stress, and churn.
- Shorter development cycles (= quicker time to market): If your goal is to deliver better software faster you want to make sure that everyone is aligned on the desired end result, feature-specific requirements, roadmap, and responsibilities. The lack of clear communication, parallel collaboration, and asynchronous work inevitably leads to technical debt, hard-to-maintain code, the need for backtracking and ad-hoc fixes, etc.
- Increased business revenue: The ability to invite and involve more stakeholders in a project ensures (a) more users, and (b) a higher adoption of your product because when distributed teams are able to achieve more together, your software becomes a key part of how they work. As Joe Sweeney said, “Multiplayer products are virality machines”.
GitHub is an excellent example of a company that has achieved global popularity because it focused on the collaborative aspect of software development: it revolutionized team-based version control and enabled collaborative coding. Most developers now take for granted the ability to enjoy features like version history, “diff” comparisons, and have a workflow built around integrating contributions from multiple collaborators.
Parallel to GitHub’s success, companies like Asana, Miro, Trello, and Figma built multi-player features at the core of their offerings and became category-defining companies that paved the way for the rise of real-time collaborative software.
How do you implement the multi-player functionality?
An application is considered multi-player if it has (1) real-time updates, (2) live playback of its collaborators’ edits (3) data integrity and prevention of conflicts, and (4) status updates for all team members.
It can be argued that multi-player technology has been around since 1968’s “The Mother of All Demos”. Two traditional approaches to building multiplayer systems are OTs and CRDTs.
- OTs (Operational Transforms) — This is a standard multi-player algorithm popularized by apps like Google Docs and in general it is used for collaborative text-based apps. It is particularly suited for editing long text documents with low memory and performance overhead but is very complicated and hard to implement correctly because of the large number of possible states.
- CRDTs (Conflict-free Replicated Data Types) — This is a collection of different data structures commonly used in distributed systems (see this list for an overview), that satisfies certain mathematical properties which guarantee eventual consistency. Once everyone completes all the updates to the file they wanted, everyone accessing the data structure will see the same thing.
Depending on your problem space (and the desired behavior for different states) you might find that you’ll need a custom approach inspired by these traditional methods. For example, if you’re a startup and value the ability to ship features quickly, OTs might be too complex. Likewise, you might get inspired by multiple separate CRDTs and use them to create the final data structure that best represents your document.
Of course, you don’t have to code this functionality from scratch! You can also look at open-source software like Yjs, text-crdt, Automerge and so many more. Alternatively, you can check out tools like Liveblocks, Ably, etc. which enable collaborative multi-player features.
This is a shortened version of the original article: The Move from Single- to Multiplayer Tooling.
If you’d like to chat about this topic, DM me on any of the socials (LinkedIn, X/Twitter, Threads, Bluesky) — I’m always open to a conversation about tech! 😊
Top comments (0)