An audio version of this article will be made available on SoundCloud shortly. You can follow Inatri on SoundCloud to be notified when the audio version of this article and others are made available.
Editors Note: Marie Markwell is currently a member of ATUnit’s technical committee, and was previously a software developer and User Advocate for Gratipay. Throughout this article, “we” refers to ATUnit.
ATUnit is a project with the goal of creating a funding platform by and for marginalized groups and activists. It was started as a response to the Gittip Crisis, which made many users feel unsafe using Gratipay (formerly Gittip). There has also, more recently, been problems with other funding platforms. However, I will leave discussion of those to other people, as I do not know enough of the details to feel comfortable discussing them at length.
Gratipay showed us many useful things: where some companies are too opaque, new approaches to welcoming contributions, and — unfortunately — what happens if you approach openness and transparency incorrectly, or are consistently misleading about how the company is organized. The conversations following the Gittip Crisis, initial conversations surrounding ATUnit, and the goals of ATUnit all come together to show us what a funding platform can become if safety and consent are prioritized: a service built by and for marginalized people which people feel safe relying on, and anyone who relies on it can have a say in how it is run.
There were many discussions around governance and general approaches to running a funding platform, and most of them seemed to come to agreement on certain things. A common theme was to make safety, consent, and comfort of both employees and users the absolute top priority, while explicitly soliciting and acting on their input. Another was to take the Open Company ideals of openness and transparency, and repurpose them as tools to achieve the aforementioned goals.
There have been ongoing problems with ATUnit since its inception, including trustworthiness, technical limitations, and a general lack of progress that came forth from those. My intent with this article is to bring them to everybody’s attention, so we can resolve them and make ATUnit become a reality.
One of the very first things ATUnit decided was that we wanted to handle governance first, to avoid many of the problems Gratipay encountered. We were discussing a corporate structure where control ultimately landed with stakeholders — regardless of any kind of committee, members would be able to say “no, I don’t think this is what we should do.”
Unfortunately, this never happened. While we did organize committees, we never decided on the overall structure, let alone actually put it into practice.
After a while, this lack of governance reared its head in: we somehow wound up with one person being “in charge,” who later simply handed over control to somebody else. This, really, should have been impossible. The most worrying aspect to me is not the people involved, nor the problems that lead to it — it is the fact that I don’t even know what amount of control was handed over. Somehow, a group that was intended to be more trustworthy and community-ran than what it is meant to replace had an unknown level of control given from one person to another.
This is, to put it simply, the single most important problem ATUnit must address. Nothing can be resolved until we know how we want to run the project, and start to actually do so.
The most painfully obvious ongoing problem with ATUnit is stagnation — after the initial month or two, activity dropped off dramatically. At one point, multiple months went by where I can find no evidence of activity. However, the details behind what caused this stagnation are even more problematic than the stagnation itself.
We decided to set up governance before code — and I must emphasize I still believe this was absolutely the correct call — but the research on governance all but stagnated months ago. This resulted in developers getting anxious. People eventually yielded, and a smaller group began to work on code.
When people started pushing forward on development, the Technical Committee (which I am a member of) had already decided on a technology stack for the main website: Haskell, using the Snap framework. Followed by seemingly-endless cries of things along the lines of “THAT IS A TERRIBLE IDEA AND YOU ARE GOING TO REGRET THIS VERY SOON.” We should have probably listened to them.
It seemed to make sense: we had some Haskell developers on-hand at the time, but they were gone for various reasons by the time development was underway. We were left with some people who kind of knew Haskell and some people who had never even looked at it.
The end result? Instead of working with solid technologies that developers understood, what we have is a Hello World application. On top of that, as of January 12th 2015, the codebase has not been updated since September 2014.
The Technical Committee needs to take a step back and look at the technology stack again. ATUnit needs to be built using technologies that we can actually get developers for now and in the future. Haskell has clearly proven not the correct choice here, even if it would make sense later on. This is a decision I was a part of, and it was wrong.
Setting aside the poor decisions regarding the technology stack for the main website, there are still other problems. There was, initially, a lot of movement between hosting. A self-hosted Trac instance that has, along with all of the information it contained (including meeting minutes!), disappeared. GitHub. Assembla. GitLab. We have never properly consolidated those and removed the old ones. Worse yet, even the issues open on GitLab — where ATUnit seems to be staying for the foreseeable future — are a bit of a mess. That can likely be solved at least partially by taking a similar approach to what Gratipay has done: a separate website (and corresponding repository) for things that are not related to the core website (e.g., PR, discussing company operations, etc), but it will require coordinated effort to do so.
As for the lost meeting minutes, we recorded those using an IRC bot. The bot responded to various commands, allowing us to build minutes during the ongoing discussion. It also, unfortunately, had a tendency to disappear very frequently. As of January 12th 2015, it has been missing for four months. I also cannot find any traces of any meeting minutes, and nobody seems to have any clue as to where they are. Even before the Trac server went down, the majority of the meeting minutes seemed to be missing. To my knowledge, the minutes from the first few days were ever actually finished.
We are disorganized. Our tools are, at best, functional but poorly wielded. At worst, they were always broken, and now seem to have disappeared. This is fucking broken.
We cannot make consistent progress until governance is sorted. We also cannot afford to have it organically build up around the technologies we use — we need to take an iterative approach, with the ability to improve or outright replace tools that are not working.
I do not care if we wind up using the solutions I mention in this article, but we need to fucking own these problems and fix them if ATUnit has any chance of succeeding. As it stands now, I fear it won’t.