Part of a series, Unsustainability at Scale
It’s Thursday afternoon. Javier, Senior Engineer, opens a pull request on the company’s open source framework of choice. It will take six hours of maintainer time to amend and merge, over two weeknights and the weekend. The pull request adds a feature of immediate use only to the company, which hires a consultancy to roll it out. The consultancy bills eight hours. Meanwhile, Javier spends 20% Friday on his own unreleased framework.
Andy and Marie are Internet friends. They hack on 3D rendering software together. Andy has a new job at a design studio doing interactive work, but Marie’s still starving for her art. Andy uses one of Marie’s libraries on a work project, and sends her a request to support another file format. Marie assumes another Andy side project. She writes the patch, but in no particular hurry. Andy misses the client deadline.
A startup selling network surveillance infrastructure to repressive national governments needs deployment orchestration. Fortunately, they find a promising, MIT-licensed tool online. The tool embodies a year’s worth of very capable engineer work. The lead contributor sports an EFF sticker on her laptop during her latest recorded conference talk. She ends with a plea for financial support. She’d made the conference on her own time and dime.
At a local meetup, Dennis takes a turn at the mic, explaining that he’s having trouble finding a paid start in programming, and would appreciate mentorship. Back by the pizza, he gets the same advice twice: contribute to open source. Dennis misses the next meetup, searching “help wanted” issues instead. An application turns up an interview, but he doesn’t get past the code challenge. The challenge seemed like real work, but they didn’t offer any pay for his time on it. The candidate with the degree gets the job.
What’s going on here? Is open source malfunctioning? If not open source, what’s gone wrong?
These kinds of faults occur all the time. If someone in a similar situation makes your next GitHub notification, will you recognize them? How?
We’re flying blind. The platform we’ve flocked to hides the context needed to recognize and steer clear of these wrongs. With even less of the overall picture than I’ve sketched in vignette above, we just don’t know any better. We may have the moral equipment to do right, but we don’t see when we ought to use it.
I have been @kemitchell since February 18, 2010. During that time, I’ve marched under many flags — -of clients, employers, universities, and foundations — -sometimes a few at a time. But @kemitchell I have been, and shall remain. Not firstname.lastname@example.org last week. Not @otherco/kyle next week.
Frankly, it couldn’t really work any other way. No more than Twitter could work if every move, job change, or relationship induced a start from scratch, a new account, a new handle, pleas to update address books.
Identity that’s constant in the social-network way — -a consequence of being fluid in all these other dimensions — -makes it possible for me to identify on a visceral level with what “@kemitchell” means on some public appliance called github.com. Identify in a way I never could with, say, a work e-mail address, or even an @gmail.com.
Folks use GitHub accounts for work all the time. And when we collaborate with others, we’d be right to ask: Is this hobby stuff? Is this for work at a company? For some paying client? Your @handle doesn’t say. You may or may not list a job on your profile page, which I have to click for, and that relationship may or may not factor here. Compared to many popular, public-Internet identity systems of the past, that’s a glaring omission.
Glaring in that frame, but otherwise, apparently not. Sometimes folks bring it up. But mostly, we just don’t. We don’t feel it necessary. The appliance, its interface, and its model of identity all discourage such feelings. There’s lower friction that way. Achievement and reputation are more portable that way. We’re comfortable asking much, much more that way.
When I deal with people who know me — -personally, professionally, or even exclusively as @kemitchell — -they identify @kemitchell with their experience. They may even project their feelings about @kemitchell onto my affiliations. If @kemitchell’s not so bad, perhaps whoever he’s willing to work for couldn’t be so bad, either. I do the same with others.
In that way, I’d like to think GitHub brings some of the transitive, mercenary rapport characteristic of independents — -coders, designers, writers, and independent professionals — -to the world of the traditionally employed. That it draws some of the W-2 masses closer to a midpoint between lifer and freelancer.
Freelance is how I got my start, and I’m biased. But the improvement I see isn’t nudging people closer to a romanticized, unbeholden Zen of 1099. Standing in the middle, and transitioning from one extreme toward another, demonstrates the continuum between, reveals choices made and to be made. Our platform of choice could do identity any number of ways. We as a community can layer any number of expectations and conventions on top of that.
GitHub’s implementation of social-network identity gives everyone on the platform a bit of the lived experience of the hired-gun coder, but not necessarily any of the education, moral or practical, that comes with it. None of the kind that would help us make the choices left to us. The vignettes at the top of this post offend the sense of propriety, the conscientious instincts, that I learned as a contractor:
Give as you take.
Talk frankly about time and money.
Slice the pie fairly.
Keep your integrity at all costs.
Pay help forward to new people.
Honest pay for honest work.
These are classic solutions to basic collective action problems, passed down by repeat players, and reproduced by each new working generation. Rules you do your part to enforce, by reputation and occasional sanction. Maxims you observe in dealings with your fiercest competitors, because nobody wants to be market leader of a scorched interpersonal wasteland. General moral principles in specialized application to matters involving money.
The primary mode of online identity for many of us ricocheted from the relative context-richness of something like email@example.com, which calls attention to business and business expectations even when they shouldn’t matter, to the context-freedom of something like @kemitchell, which doesn’t hint any affiliation or pecuniary interest even when it should. The longest-experienced, most reflective old-timer can make greenhorn mistakes with blinders on. The same blinders make it damn hard to spot predators, drawn to any margin they can squeeze, as if by the scent of blood.
Meanwhile, a whole new generation is coming up. They’re on GitHub well before their first jobs.
They shouldn’t confuse the default in their time for a natural order. There have always been choices to make in how we identify ourselves, and how we identify and interact with others. There have always been moral dimensions to those choices. There always will be, no matter what defaults the tools and platforms of the moment happen to favor.
Laying it out just as plainly as I can:
- The way identity works on GitHub helps us forget about business and other affiliations. Sometimes we should. Sometimes we shouldn’t. That’s on us.
- GitHub invites us to fill in thoughts and feelings about a system mostly chock full of strangers with thoughts and feelings about the few of those people we know. Sometimes that’s saintly. Sometimes it’s blind. We have to stay open, and keep learning about each other.
- Stripping context away from interactions and exchanges stops us remembering and applying rules of conscience we learn in higher-bandwidth situations. Some of those guidelines are baggage. Some of them are very wise. GitHub won’t teach you the guidelines, or the difference.
When we interact people-to-people on GitHub, and money finds its way into the mix, say on a pull request for a feature we need at work, we face a choice. One we might prefer to ignore. Assume both sides know, somehow, that the context has gone from pleasure to business. GitHub doesn’t help much there, and that’s the first problem. But taking it for granted, do we adjust our behavior to reflect?
No. Largely, we do not.
Where I see exceptions, it’s usually pretty easy to spot the developers with meaningful entrepreneur or freelance experience. In other words, developers comfortable with business, and capable of taking the switch in stride, as an opportunity. Can I put time on something else to free you up for this? Can I pay you to land this faster? You’re already working on the project; want to do that full time? How can I establish that I respect you, and that you’ll get a fair shake each time I come calling, and you answer?
On the flip side, students, hobbyists, and employees sufficiently insulated from “the business end of business” tend to say nothing at all about money or any other kind of exchange on GitHub, ever. Why would they? Those they know are trying to learn, or toying around, or on salary. Time is never lost. Experience and dopamine are only gained. Talking money makes more awkwardness and delay, not more right. When you’re insulated from those concerns, it’s nice to stay that way, and easy to forget that others aren’t.
In informal, non-business situations, which even the businessiest of businesspeople preserve in their private lives, we trust these imbalances to work themselves out. We expect any aggregate loss to be offset by something we can’t or don’t bother counting. I close your PR. Later on, you’ll close one of mine. Or one of my friend’s, whose time I sopped up on a bug.
Nobody really wants to count up, value, and settle all these scores, only to end up near enough to zeroes all the way ‘round. So why bother keeping score?
Stepping back, we all know the asymmetries that make zeroes unlikely. We know that open source thrives on radical imbalance between developer effort going in and user benefit going out, that even free-as-in-beer use creates incrementally more demand on maintainers. We know that when buddy-buddy becomes buddy-business, it benefits business to make on like buddy-buddy if it can, that budgets, incentives, and financial controls encourage doing so as long and as often as possible. We know that compensation in kind really only adds up if you are also a business, and running the kind of proprietary, one-way model that makes comparable cash.
We know, in short, that we could probably count up the gives and takes for all of our friends’ hobby work on GitHub, and end up near zeroes as far as we go. But there are other accounts out there drawn deeply in the negative. The credits offsetting those debits don’t count for less being spread across many volunteers. Volunteers who couldn’t have been worked legally, and ethically, even as interns, for nothing. Volunteers who would never describe other work directly benefiting for-profit firms with the v-word.
Other social networks have weathered major storms of controversy about sponsored content, product placements, and other ways business sneaks by in stealth. Conscientious users settled on norms of disclosure to fill the void. Conscientious platforms built disclosure right into the interface, into policy. In part because regulators came around asking questions.
GitHub is for making as well as consuming, and much of what gets made there is free to consume. But how we spend our own time and others’ should be no less informed than how we choose to spend time’s wages. Inducing someone else to spend time for my commercial benefit without telling them is no less morally fraught than paying apparently disinterested community members to draw eyeballs to my products and services. There are other areas where tools and platforms have fallen down in communicating affiliation, such as in licensing. But none of those mechanisms is as crucial as how we work together.
We could get more good done, and do less wrong, by transparently acknowledging which hat we wear when asking and giving work on open source software. We should accept the momentary awkwardness, an awkwardness that will pass in time, in posing questions about others’ affiliations and support. Bringing that information out into the open, more of us would be able to make better choices, more of the time. Choices that would make open source a better lived experience for individuals, and better open source code in the long run, besides.
Socialize a clear, visual language for project support status. Mention in our pull requests whether we’re working, and for whom. Disclose when our preferences in tools, frameworks, and services follow our business interests. Ask people we do and don’t know whether they need financial help, and whether they have help to give, to keep the code getting better and the choice to contribute a sane, just, and positive life experience.