Stay calm and untangle your GitHub notifications
Or, how Octobox tames the garden fairies
Ben & Andrew have been working in open source sustainability since 2015. Their first project together, Libraries.io, tracked the most popular packages in open source software. They used the data collected to identify what we now call ‘digital infrastructure’ and to highlight projects at risk.
These days, they work full-time on Octobox, an open source application that helps developers ‘untangle their GitHub notifications’.
I love being able to sort through notifications outside of my email inbox (which I like to keep as close to 0 as possible). What a beauty!
Pia: Can you tell me a little bit about Octobox?
Ben: Like Libraries.io, Octobox was initially a reaction to GitHub’s solution being poor. GitHub notifications are like garden fairies: you might see them for a moment and then they’re gone.
Octobox takes GitHub’s notifications and places them in an inbox paradigm, which means no more ethereal notifications. We add the kind of features you’d expect in an email client: archiving, filtering, etc, and complement them with live issues, with PR and CI status updates to make you more effective and efficient in your work.
GitHub notifications are like garden fairies: you might see them for a moment and then they’re gone.
Octobox is built for anyone struggling under the weight of notifications and those who’s workflow centres on issues, PRs, comments and commits. If that sounds like you, then you can get started for free at octobox.io (and installing the GitHub app for maximum effect). We’ll sync all your current notifications, then you’re good to go.
Pia: Can you give us some pro tips?
Ben: If it’s your first time using Octobox, then you probably want to clear your backlog. Start by archiving all your closed and merged notifications — hit the pre-filters in the sidebar, select all, and hit archive. Next, merge all the passing PRs, especially those from bots. Use the search and filter for ‘bot:true status:success state:open’ (and pin that search in the sidebar). Finally, triage new issues: hit ‘unlabelled’ in the sidebar and that should give you the right list.
Pia: At SustainOSS, we defined sustainability in a broad sense, to include maintainer health, community ,and financial sustainability. Is Octobox aligned with that ideal?
Ben: Yup. Our goals for Octobox are straightforward: help alleviate the problems maintainers have today. And show — rather than tell — the world how we might create a sustainable future for open source software, by building responsible open source businesses that care for their communities and dependencies as much as they care for their profits.
Pia: You have three options for using Octobox: self-hosted, free public repository, and a paid private repos. Can you talk about these?
Ben: Firstly, Octobox is developed in the open under an Affero GPL licence. Andrew and I are kind of hard-wired to create software this way; it has a lot of advantages early on. A proportion of the initial development was supported by contributors at Shopify and GitHub for instance, and both self-host their own services. Shopify runs a larger database than even our public one.
Our goals for Octobox are straightforward: help alleviate the problems maintainers have today. And build a responsible open source business that cares for communities and dependencies as much as profits.
Going back to our goals: we want to help open source maintainers maximise the time they dedicate to their projects, to make them more effective with the time they choose to give. There’s no way we’re going to charge them for that, so our financial sustainability relies heavily on paid access for proprietary projects.
It’s no surprise that most companies share the same challenges as open source maintainers — an endless stream of notification spam — and they want a developer workflow that works with the tools they already use.
Andrew and I like to test our assumptions by experimenting and proving them out, and Octobox is kind of a giant experiment. Our first research question was, ‘Do people want to support commercial providers, or communities directly?’ We offer the same access to donors of equivalent value on Open Collective as we do those who pay Octobox Ltd. through the GitHub marketplace.
Pia: What do you expect to see in the community vs enterprise options? What are the incentives for someone to choose?
Ben: It’s early days, but we’ll do everything we can to ensure that the service is split on public vs. private projects, so your incentives are to open source your software or pay for access. Our challenge at the moment is to make this a personal decision rather than relying on an organisation to authorise use of a GitHub app for access to Octobox.io.
Companies like GitHub became successful from the bottom-up: developers started coming into work and saying they had to have access to GitHub.
We’re currently looking for ways to utilise the network effects of developer communities to broaden usage, and for ways to let developers use Octobox at work. My view is that companies like GitHub became successful from the bottom-up: developers started coming into work and saying they had to have access to GitHub because that’s how they worked together. So I can see us developing the roadmap — which is public and open to contributions — in that direction, making Octobox work better for teams and to build things in Octobox rather than reimagining GitHub’s interfaces.
Pia: What are you thinking in terms of governance for both the community and octobox.io?
At the moment, the Octobox community is quite small. There are about 90 contributors, ten of whom are maintainers with commit access. We’re able to keep everyone informed about what we’re doing and we keep channels open for feedback. As we grow, we’ll be more explicit about the governance, following something inspired by Elinor Ostrom’s principles for institutional design. I have a plan for popularising this approach over at tldrgovernance.com (which you could call a pre-announcement of sorts).
We’re playing both sides of the financial sustainability model. We are able to let the users decide who they wish to support, predominantly. As a protection measure, Octobox Ltd. guarantees at least 15% of its annual revenue to the community, forever. In time, we’ll use this to support paid work on Octobox and to distribute funds the maintainers of our dependencies. We believe that if every company who builds their profits on open source software gave back, then there would be no open source sustainability problem, at least not as we have begun to define it today.
As a protection measure Octobox Ltd. guarantees at least 15% of its annual revenue to the community, forever. If every company who builds their profits on open source software gave back, then there would be no open source sustainability problem.
Pia: Which types of projects do you think this model will work for?
Ben: We’re fortunate. We are able to provide a direct service for end users that they will (and do!) pay for. We’re in the same category of project as Sentry.io in this regard. I would say that this approach is appropriate for any open source project with a hosted ‘de-facto’ public service, or the ability to create one.
Pia: Any last thoughts?
Let’s face it: we also had the freedom and the privilege to be able to do this. Andrew had the time to dedicate to the start of this project and — due to the terms of our exit from our last employer — we’ve both had the financial support to get Octobox to where it is today. I sometimes talk about a solution to the sustainability problem as ‘creating a system that’s not based on privilege and philanthropy’. For the moment, I think our responsibility as a community is to share the income from direct user-services today with the maintainers who will provide for us tomorrow.
I sometimes talk about a solution to the sustainability problem as ‘creating a system that’s not based on privilege and philanthropy’,
Pia: Thanks Ben.