There has been explosive innovation for collaborative work online: Figma for design, Notion for wikis, Google Docs for writing, FigJam for brainstorming, to name a few. As teams are increasingly working remotely, these tools are re-defining the future of how we do work, together.
Think about the last time you wrote something using a local text editor like Microsoft Word. If you wanted to share the document with your team, you needed to send them a copy of the file. And for every change or suggestion, you’re stuck sending iterative files back and forth and manually merging asynchronous changes.
On the other hand, collaboration is built into the Google Docs platform. Any time you create a document, it’s instantly shareable and synchronized for all collaborators. You’re working together, reacting to each others’ changes in real-time, instead of merging changes after-the-fact. This kind of realtime collaboration makes a huge difference in how we work together.
GitHub already facilitates collaboration, but only starting after code has been pushed to Git. Can we also help when and where the work happens: while the code is being written?
Collaborative development comes in many forms, and many companies are innovating heavily in this space. A common pattern is multiple cursors — our team uses Visual Studio Code’s Live Share extension often. With some configuration, this is available in Codespaces today:
At the end of the day, though, this is only an incremental update to our existing workflow. Developer collaboration (like pair programming) involves more than simultaneously typing into the same text buffer; it involves a broad and real-time exchange of context and knowledge, both of which can be spread out amongst teams, codebases, and projects.
By looking at how developers currently work, we can start to shed light on these many facets of collaboration.
This is a lot of context to keep track of. And this context needs to be dug up every time the feature is worked on, for every developer working on it! Every project has a huge amount of context behind it and there’s no standard place to or way of storing this information.
Against the backdrop of a proliferation of real-time collaborative tools, GitHub has an opportunity to redefine its motto, "social coding." Developers worldwide are already moving their entire working environments to the browser via Codespaces; a natural enhancement to this movement would be the addition of real-time collaborative and project-planning features.
Now that we have a unified workspace, we can easily share all of that context and work in collaboration.
You can imagine a workflow where you can see what space everyone is working in (on an organization page, repository page, or on, say, dev.github.com):
If you find something you want to work on, click it to instantly open the space:
With all of the context for a project in one place, it’s natural to enable meaningful collaboration: work on the entire project together.
Such a collaborative workflow makes us question the current model of code ownership. How does a workspace connect to Git, and who authored the changes? There are many answers here, and worth much further exploration!
With this foundation of a unified place to work, we’ll be able to build even higher:
For newer coders or for small projects, having basic tools built-in lets them jump right into the work! Create a repo and start a workspace - it’s as easy as that!
For those teams who want more complex tools or want to integrate with external services, we can expose a structured API for creating new plugins.
By allowing end users to extend what their Workspace is capable of, we can provide a foundation for enabling an endless number of workflows.
Once the context around a feature or project is unified in one place, we can make that workspace easily shareable, easily extensible, and a medium for meaningful collaboration.