Building technology has always been hard. Collaborating with others to build technology has always been even harder. It has always been the case though that the best technology has been built by the collaboration of diverse groups of people amongst whom exists a variety of skills, both technical and non-technical. The challenge of finding the best ways to converge these varied skill sets toward the achievement of a shared goal has been a never ending work, yielding as many innovations and iterations as computer science itself.
As the solution space has matured, so too has the set of tools available to support those solutions. We have reached an age of finely tuned feature-rich software products which help make collaboration, particularly across space, the most seamless it’s ever been. These modern tools are the culmination of decades of trial and error in both methodology and technology. Code for Philly, along with many other Code for America brigades, has embraced the best of these software products, understanding their potential to help facilitate the success of cross-functional teams of people who want to deliver technology to their own communities as a public good. At the forefront of these products has been GitHub and Slack, which together have become something of a de facto standard in civic tech collaboration.
GitHub and Slack offer an immense amount of benefits to collaborators. These platforms have helped the civic tech community break down geographic barriers, shorten feedback loops, and simplify the onboarding of new teams and civic hackers, just to name a few. They have provided an avenue for the open source community to gain access to capabilities previously only accessible to large enterprises with handsome budgets. The success of these tools in fostering the growth of civic tech collaboration offers us many lessons in how to best help our teams achieve their goals. Wrapped up within all of this success however, there lays a dormant dragon.
We have, as a civic tech community, allowed ourselves to become complacent with the fact that these platforms are close-walled ecosystems. This is, without a doubt, a glaring philosophical incompatibility with our mission in civic technology; an irreconcilable hypocrisy. We all take on the mission of providing technology as a public good, while access to our technology and all the work that was invested in building it (we too often overlook the fact that the documented act of building this technology is every bit as valuable as the technology itself) is not in fact as Free as the code we produce; these artifacts are instead available at the pleasure of the benevolent dictators who control the platforms we have become so dependent on. All the reasons we choose to volunteer our time toward this mission should be the same reasons that this fact does not rest well with us.
There will be those amongst us who consider themselves more practical in mind, unencumbered by pure principle in the interest of embracing more pragmatic considerations. Here too, the way in which we have outsourced ownership of process and product should be seen as a concern to the health and welfare of civic tech. There are a multitude of reasons which these closed systems are, in the most practical sense, unhelpful to the achievement of our end goals. Amongst them:
- Rug Pulls: While these platforms may be low to zero cost for us to use, both of them have business models centered around their enterprise customers. While there is nothing ethically (or certainly practically) wrong with this, it does mean that features are introduced, gated, deprecated, and removed in accordance with that priority. Small and open source organizations do not gain access to more useful features (e.g., ref level access control on GitHub) or worse yet, can be subject to losing useful features because they were uninteresting to enterprise customers (e.g., git protocol deprecation).
- Inter-organizational information flow: Slack in particular is a tightly closed environment for information flow. Collaborating across organizations on Slack is a paid feature not accessible to most open source communities. The Code for America brigade network is one of distributed organized groups all loosely working toward the same goal, operating under similar constraints, sharing a lot of the same problems. The heavy adoption of Slack as a collaboration platform has resulted in obscenely high barriers to sharing and reusing knowledge amongst ourselves related to these commonalities.
- Public accessibility and ownership of information: The same traits of Slack collaboration which limit inter-organizational information flow also limit the availability of this information to the general public. This is an outcome which we should regard every bit as unacceptable as closed-source civic technology. Technology as a public good demands not only that the resulting technology is publicly available, but that all of the inputs which went into building it are just as much so. While collaboration on GitHub is more open, revisit point 1 to realize there are no guarantees around things like future access or retention, and it cannot be conflated with true openness in which data is published in an open format for public consumption, republishing, archiving, searching, etc.
- Shareable models: Groups like Code for Philly can’t compete with the resources and reach of the large enterprises seeking to disrupt and centralize our world, but what we do have going for us is our numbers, diversity, and wide distribution. In order for our numbers and distribution to be a strength rather than a weakness, we need to be able to collaboratively build up our tools and practices. When these tools and practices are built within closed systems to capture quick wins, we often end up blazing a trail that can’t be freely followed. Code for Philly’s own journey stands as an example of this; as one of the earliest brigades to request sponsorship from Slack, we were granted an unlimited plan with access to enterprise Single Sign On. We have been able to leverage this SSO capability to create a low-friction bridge directly into our Slack space from our community website. Brigades looking to replicate this model today however will find themselves inhibited by a change in Slack’s policy (another ode to point 1) which now rarely grants unlimited history to communities, and never grants enterprise SSO. Our path can no longer be followed, just as we in turn cannot follow the paths other brigades have forged within other closed systems.
This list of practical inhibitions to our mission is by no means exhaustive, but provides a strong foundation upon which we as a civic tech community can begin a difficult interrogation of how we choose to pursue it. We all aim to produce technology for the public good, but we cannot lose sight of the critical fact that how we produce it directly and majorly impacts how much good we have truly done the public.
We understand that Slack and GitHub are both tools that are here to stay-- often the practical considerations of running an organization must take precedence, and that can mean using a closed tool to solve a problem which cannot be adequately solved by a comparable Free option or for which no comparable Free option exists. The goal is not to eradicate these tools which have enabled so much success amongst civic tech projects; rather, the goal is to radically reevaluate our relationship with them, and challenge ourselves to disentangle our use of them from our core values and mission. Meeting that challenge means that when there are comparable Free options available, it is our imperative to evaluate that factor with great weight and be prepared to make reasonable sacrifices in usability and setup cost in exchange for a long term strengthening of that public ownership and openness which is the very bedrock value of civic technology.
As a first step toward reducing our dependence on closed collaboration platforms, we are moving some of our Code for Philly core team discussions out of Slack and into our Discourse forum, where we can collaborate more publicly and begin to reclaim ownership of the record of process which is such a critical component of truly open development. This first step will not be our last; we hope that by our example we can begin to inspire our projects to follow suit, and that they may in turn stand as models of success who will inspire others. What we are starting out to accomplish within our civic tech group is nothing short of a major culture change, but the long running history of civic contribution within this brigade and the incredible breadth of our contributers who embrace the most high-minded philisophical aspects of our mission make us supremely confident that we do not set out to inspire this change alone. It’s time for a new standard.
Attribution:
Additional Reading: