A Bridge Too Far
Every startup story has a beginning, and an end
TL;DR the Bridge Seat Cooperative experiment is over, at least in its current form. I (Strypey) am done with SubStack, due to its escalating lock-in, promotion of actual Neo-nazis, and overall enshittification. If you want to keep receiving posts about the subjects I wrote about here, or future experiments with supporting community-hosting of fediverse servers, I’d love to have you as a subscriber to the Disintermedia blog in its new home here at disintermedia.net.nz.
After months of inactivity, I’ve decided to declare the Bridge Seat project a success and close up shop.
I’d like to thank everyone who backed the vision and tried to help us realise it. Particularly Dan Faulknor from Prodigi, a kiwi hosting company with onshore datacentres, and Bryan Manske from a then-new US-based host called BlinkinBlox, both of whom offered us free use of their spare servers for prototyping our hosting infrastructure. Of course they would have been our first choice of upstream hosts, if and when we ever got to the point of having paying customers. But that was a gamble for them, one that hasn’t yet paid off, so I really appreciate their willingness to support our experiment.
I’d also like to thank Matt from Snikket, who agreed to a service trade between his hosting service and ours, although we never got as far as using his service or being able to reciprocate. Finally, Alanna and Ember from OpenCollective.nz, who agreed in principle to be our fiscal host until we could get our own legal structure set up. Although when I followed up with Alanna more recently, she told me they’ve since shut down their operation, which is a shame.
The way I worded this announcement might be a bit confusing. If I’m declaring that the co-up1 was a success, why am I closing up shop? Let me explain.
Bridge Seat was an economic and social experiment, designed to test a number of hypotheses;
1) There is a market for managed hosting of fediverse servers.
2) There are people who really want their services hosted in Aotearoa, in particular, especially mission-driven organisations or those who value digital sovereignty, privacy, etc.
Because there is demand …
3) An onshore fediverse host in Aotearoa will be able to attract enough customers to cover the cost of three modest but reasonable salaries, plus operating expenses.
4) We will be able to find seed funding for a year or 2, either through crowdfunding from future customers, or from angel investors who support mission-orientated startups.
5) A worker-owner cooperative, like Loomio, is the right approach for setting up a managed hosting service.
6) The seed group working on a co-up can succeed if they have a base of shared values, and either already know each other reasonably well, or commit to living in the same area so regular in-person gatherings are possible.
And finally …
7) A group of people I knew from a couple of shared houses I’d lived in were the right people to launch of worker-owned co-op with. Because even though we were geographically scattered, I knew them well, and I knew they’d been working as freelancers so I was confident they had the skills to get the work done.
An experiment is only a failure if the method is botched and no results are produced. But although Bridge Seat never managed to get any production servers up and running - not even for dogfooding services under bridgeseat.nz - it produced useful insights into all seven of these hypotheses. Let’s go through them one by one.
1) There is a market for managed hosting of fediverse servers.
One of the things I tend to do when I consider starting a new project is to follow what I call the Kalashnikov Principle, based on a quote from the inventor of the AK-47;
“Before attempting to create something new, it is vital to have a good appreciation of everything that already exists in this field.”
As a result, I’ve spent a lot of time searching the web and talking to fediverse folks about fediverse-hosting as-a-service. Turns out there are a bunch of managed hosting providers, and a bunch of people happily using them to house and feed their servers. So far, this hypothesis seems to hold.
2) There are people who really want their services hosted in Aotearoa.
A number of people responded positively to this idea, so there is definitely some demand there. Especially if you consider that fediverse hosting could include services like WordPress (with ActivityPub plug-in), which many organisations already pay to host overseas, and NextCloud, which could be attractive to organisations wanting to deGoggle, or reduce their dependence on the rapidly enshittifying Office365.
3) An onshore fediverse host in Aotearoa will be able to attract enough customers to cover costs
Whether this interest in the service is matched by a willingness and ability to pay is still untested, and uncertain. I know of businesses and NGOs currently spending absurd amounts of money hosting on AWS, or paying helpdesk companies that run digital protection racket to keep their computer systems working. So in theory, there is money being spent that could be redirected to a co-op hosting services onshore on a not-for-profit basis, and supporting on-premises hosting.
But unfortunately we found ourselves trying to bootstrap a new business during a crippling recession, when most organisations were trying to cut fixed costs, not take on new ones. Although if we’d managed to get started a year or two earlier, the recession might have wiped out a bunch of our customers after we’d already burned through our initial funding. So maybe the timing was a mercy. Whether we can successfully build an onshore hosting service if and when the economy starts to recover, remains an open question.
4) We will be able to find seed funding for a year or 2, either through crowdfunding or angel investors.
This one I’m still not sure about either, for the same reasons. If not enough organisations can afford the services we want to offer, crowdfunding wouldn’t work. Few if any angel investors, grant funders or philanthropists who might support a social enterprise like ours are keen to support an experimental new venture in lean times. But maybe we were a bit ahead of our time? Here’s hoping.
5) A worker-owner cooperative, like Loomio, is the right approach for setting up a managed hosting service.
I suspect not. The reason I think this worked for Loomio is that they do one thing and do it well; maintaining software and servers for Loomio.com. A single service they can focus on scaling up as needed. Whereas a managed hosting service with 3 paid staff needs to host hundreds of services to cover costs. There’s a lot more moving parts, and a lot more trust involved in caring for the private data of hundreds of organisations. A lot of responsibility - both technical and governance - on the shoulders of 3-5 people.
A while into the process of trying to set up Bridge Seat, I started to think it might be better to bootstrap a service like this as a customer-owned co-op. For it to work financially, the number of customers has to be 2 or 3 decimal points bigger than the number of staff. In a consumer co-op, a bunch of the prospective customers wanting the service to exist could organise governance, fundraising, etc. While technical staff do what needs to be done to make this viable, securing their place as the initial hires once sufficient funds are raised.
Later I started wondering if it could work to structure something like Bridge Seat as a sort of producer co-op. Gathering freelancers and small companies (ideally co-ops or social enterprises) who have the capacity to offer sustainable hosting services, and connecting them with people and organisations who need or want them. I recently discovered SEPHEO (Self-Employed People Helping Each Other), which works on that sort of model. So that gave me an inkling I might be on the right track. These are both models I’m keen to experiment with in the future, but the latter is probably the easier one to bootstrap.
6) The seed group of a startup can succeed if they either know each other well in advance, or commit to living in the same area so regular in-person gatherings are possible.
This hypothesis was based on my first experience trying to start a worker-owned hosting co-op, around the time Loomio was getting started. The seed group for that co-op were mostly unknown to each other, having been introduced through an open membership mailing list run by the NZ Open Source Society. We were also spread around the country.
Things went fairly smoothly at first, but when we got into our first serious disagreements, things got … unpleasant. We didn’t have what we needed to manage this conflict productively, and before long, the atmosphere got so toxic I decided to tap out. I assumed I was the problem, and hoped that without me in the way, the co-op could finally take off. Unfortunately that’s not the way it played out, and as far as I know it never really got off the ground.
After that experience, I thought maybe a group of people with strong, pre-established relationships might cope better when the going got tough.
7) A group of skilled people I knew from a couple of shared houses I’d lived in were the right people to launch a worker-owned co-op with.
My experience with Bridge Seat suggests that a lack of familiarity wasn’t really the problem in that first co-op, so much as a lack of processes for managing conflict. Planned out and agreed to, in writing, before the going gets tough.
Overall, I feel like I’ve learned a lot from trying to start this co-op. For a bit of insight into what we tried, and why I might have come to these conclusions, read on.
An aside …
It feels a bit odd not to be naming my co-up partners in this wrap up, especially given how light this story is on gory details. In some ways it would be only fair for their role in Bridge Seat to become part of their professional reputation, just as it will definitely become a part of mine.
However, for whatever reasons, I never got around to finishing the blog post introducing my initial partners, nor did I introduce the new ones as they came on board. So it seems a little churlish to start naming names now, as if I’m trying to pass off responsibility for the co-up not working out as I hoped. The fact is, Bridge Seat was my baby from the start, and everything that happened was a result of my vision, ideas and leadership (or lack thereof), as much as anything my partners did or didn’t do. So, no real names.
The story of Bridge Seat Cooperative
The first two people I approached about starting a hosting co-op were friends I’d lived with in a shared house for a few months each, who I’ll call Chris and Nico. I was hoping that because when I lived with them both we’d spent a lot of time talking about tech and politics, and because they’d worked together on freelance contracting jobs since then, I thought we could all work together as a tight team.
About a year in, Nico decided to pull back from the establishment work, despite liking the co-op concept, due to being more of a programmer than a server admin. So we recruited a young computer science student I’ll call Lou, who I’d lived with in a different shared house, where they’d showed me working servers they’d built in their bedroom. We also pulled in a graphic designer to work on UX stuff, whose partner had lived with some of us too, and we were all pretty familiar with them.
Keeping it in the family. What could go wrong?
My co-up partners and I have never had a chance to debrief on exactly why the wheels feels off. So while I could go into great detail on what it all looked like from my point of view, in fairness to them, I’ll just say that for whatever reasons we seemed to lose momentum as soon after we scaled up from three to five.
Our freshly recruited designer had gone incommunicado immediately upon joining the group chat. So with Nico our programmer stepping back from active duty, although still supportive of the project, there were three of us left actively working on the co-up.
My main goal at that point was to find a way to fund our first year or two of salaries, so we could all dedicate paid time to Bridge Seat work. Chris and Lou had agreed in principle to set up a small cluster of demonstration services - just five servers running the same software - to prove to potential customers/ investors that we could actually do the job. I very much wanted to avoid a situation where we got the funding, spent the money, and still hadn’t got enough technical infrastructure set up to start bringing in revenue.
At one point I organised a workshop session with Dave Lane (Lightweight) a very busy friend who single-handedly runs hundreds of services, across a range of organisations2. The idea was to give Chris and Lou the opportunity to pick Dave’s brains about how he manages his infrastructure, get ideas for tools and techniques to try, and help them identify any unknown unknowns they hadn’t accounted for yet in their infrastructure prototyping.
Again, I won’t go into the details, but this resulted in Chris, the remaining original partner making an abrupt decision to completely quit the project. This motivated me to step up as an apprentice server admin myself, and meet regularly with our remaining server admin Lou - who still lives in the same city as me - in an attempt to get some basic services up and running, Which I could use as a demo when I pitched to funders.
Unfortunately, after a couple of these sessions, Lou made it clear that they didn’t feel comfortable taking the technical lead on hosting services for paying customers. So I had a couple of options for where to go from here, one of which was to recruit a more experienced admin to take the technical lead. Otherwise, I needed to put on my thinking cap and dream up a way to rejig the project to work with the combo of skills, experience and confidence we were left with; a software engineer, a junior server admin, and me.
At the same time, I learned that the Takahē project was looking for new maintainers. Andrew, the programmer who’d created it, had come to the conclusion that taking it to the next level would require more than he could put into it as an itch-scratching hobby project. But he wasn’t keen to quit a well paid job to work on a startup, even if he could find funding to pay him to work on it.
Takahē is an ActivityPub server that can host multiple domains on one server. So after reading Andrew’s blog post about this I had a brainwave; this could be my solution! Bridge Seat could take over management of the Takahē project, with Andrew remaining involved as much or as little as he liked. This could be our main hosted offering, with other software hosted on the side as requested.
So in August 2024, I contacted Andrew with a rough proposal. Our programmer could take over as lead developer. Our admin could take over hosting of takehē.social and pivot our hosting service to hosting BYOD accounts on Takahē servers. Both under Andrew’s capable mentorship. I could continue as chief cook and bottlewasher, doing all the glue work around the edges, including figuring out how to fund it all. Andrew was cautiously interested, and we hashed out the details of how it could all work over a series of emails.
As with any negotiation there were compromises involved. Andrew wanted to continue code development on GritHub, and as it turned out, our programmer Nico agreed with him. This was something I was deeply uncomfortable with at the time, when the enshittification of GH under BorgSoft ownership was already predictable, and it’s certainly not something I’d agree to now. This got me worrying that our value alignment wasn’t as strong as I would have expected.
However, over the course a few emails, over a few months, Andrew and I drafted an in-principle agreement on how to work together on Takahē. Nico our programmer was on board to take the lead on development, presuming I could secure funding for a salary. So far, so good.
Sadly by this point Lou had got busy, and was no longer able to commit regular time to the project. Among other things they’d returned to their computer science studies, which I’d like to think was at least partially inspired by the new horizons opened up by their time with Bridge Seat. So now, as well as lacking funding, I was also lacking server admin skills. Which was the key to the whole business proposition, and the main thing I’d tried to make sure I had in place from day one..
I needed a new strategy. Again. But by this point my personal life had become a bit of a rollercoaster ride, with a couple of unplanned house moves in 2024, and some big changes in my family situation that shifted my priorities pretty significantly. So Bridge Seat got put on the backburner for a year, which brings us up to to the present.
Put it all together and I’ve realised it just isn’t a good time to be trying to start a social enterprise or get funding. Besides, Bridge Seat was always a bit of placeholder name, and the co-op was really about the people I’d gathered to build it together. Now that they’ve all moved on, trying to carry on with Bridge Seat seems like flogging a dead horse.
But I haven’t given up on the vision of hosting online services for the people of Aotearoa, using servers located in Aotearoa, and having hosting arrangements with vendors in other countries to host customers there. This is my second attempt to create a hosting service as a co-op, and I doubt it will be my last.
I’ll take some time reflect on the Bridge Seat experience, rethink the structure and bootstrapping strategy, and I’ll continue to grow my own server wrangling skills. Then chances are I’ll try again, using on or more of the approaches I discussed earlier. If I do, you’ll read about it in a post on the Disintermedia blog. Watch that space!
Thanks again to everyone who joined the crew or offered help and support. It was an adventure, and a pleasure working with you all. Let’s do it again sometime.
Images:
“Broken seat on the river bank - geograph.org.uk - 4683247“ by Richard Humphrey, licensed CC BY-SA 2.0.
“Hotel Ca’ Sagredo - Grand Canal - Rialto - Venice Italy Venezia - Creative Commons by gnuckx“ by gnuckx, marked with CC0 1.0.
1 A startup structured as a co-op.
2 Dave is also helping me out with hosting for the Disintermedia.net.nz blog and email, and helping me upskill so I can eventually host them myself, for which I’m very grateful.
