I Don’t Want to Know What “Open Source” MeansI am he as you are he as you are me and we are all on GitHub.
There is frustration with the term “open source”. New developers aren’t steeped in the history of the Open Source Definition, the semi-schism with Free Software, the SCO circus, or MS FUD. Those who do remember seem ever more out of touch, lurking on their Mailmans and Bugzillas, hoarding contributor license agreements, and coding in sexless languages with all the industry buzz of used Tupperware. But “open source” lingers on, divorced from the context that gave it first meaning, as a rallying cry and identity for all those people and practices—an increasingly, perhaps bewilderingly, diverse community.
It’s troubling to meet people with whom you don’t relate, who talk and work and swagger very differently than you do, but describe themselves in terms intimately tied to your self-image. This irks especially when—whether you admit it or not—you define yourself primarily in the negative, as a counterculture, and the one flying your flag reads strong in the culture you think you’re countering. When the bully who eats your lunch shows up in your favorite band’s t-shirt … well, you get the idea.
Reflex
There are a couple natural reactions to that kind of social collision, which we’ve all seen many times in other contexts before.
Plant a new flag, with a select cut of new people, that feels edgy, fresh, conspiratorial, exclusive. Ditch the Beat bongos and turtleneck; learn the sitar. Ditch the sitar; learn to disco. Forget disco; it’s GitHub now. Or IPFS. Or shell accounts at the hackerspace. Hell, I’m a lawyer. I don’t know.
But of course that’s youthful and foolish and everybody did it when they were young and felt sexy but then grew up. But the work that saved us from The Bad Old Days before “Open Source” took wit and hard work and a lot of compromise. Somehow all of that’s been forgotten, and we’re at risk of sliding back. Do they really think “open” and “free” won, now that we all use a closed-source, proprietary social network without so much as a public bug tracker?
I know these reflexes well. I am dead-to-rights for both.
I defined myself in opposition to “proprietary software”, and especially Microsoft, when I wrote code for money. I’d lead out with “open source”, but if you asked me what that meant, it was probably “not ASP.Net”, “not ColdFusion”, and so on. And I allowed myself to see anyone—which was closer to everyone in Austin, where I came up—who wrote software for a living in a cube and khaki pants as hobbled, hidebound, drone-like. Rather than learn from those fighting for good compromises in the real world—or, frankly, contribute much code—I battened down the hatches on my own insecurity. If I’d been smarter, I’d’ve got a little further away from the university zone and given the Microsoft Certified Working Stiffs a listen. Turns out their free time is where most of the software buoying “my community” was coming from.
As an attorney, for one, and a coder who came up on FSF software, for two, it kills me to see students and pre-exit programmers write off good licensing hygiene as unnecessary. It makes me queasy to read, via the closed, hood-welded-shut social network du jour, that “open source has won”. How smoothly both disdain for “corporate interests” assailing community values, on the one hand, and utter disdain for the GPL, its politics and its moralism, on the other, roll off the tongue. It’s a cruel, cruel world.
Instinct
Where does that leave me?
First: I am fine with a fuzzy meaning of “open source”. If that means I am never quite sure what it means when others use it, I’ll manage. The same is true of most other named generalizations in software—“test-driven development”, “REST”, “functional”—and in other vitally important areas—“nonprofit”, “independent”, “proportional”. It’s a problem with words. A distributed consensus problem.
If the process dulls the fine edges of the Open Source Definition, which I consider one of the most laudable inter-generational bequests in programmingdom, then so be it. Its political foundation has shifted, but its value as an artifact and teacher aren’t lost, and won’t be while I still type. If licensing is the focus, it’s easy to get more specific. Just a handful of OSD-compliant licenses make up the vast majority of the “open source world”. “MIT” or “EPL 1.0” will do.
It’s all a meager price to pay if “open source” becomes an inclusive identity badge for lots of people trying to do software together on the Internet, rather than a resharpened wedge or a well-demarcated historical curiosity.
If that seems fuzzy, take it out of context: If I play guitar with my fingers and you play with a pick, we are both “guitarists”. After a beer or two, we might argue whether lapsteel or medieval lute players count. But only if we think too much about it. They’re welcome at the conf if they want in, because the point is that playing guitars—and my Telecaster might be closer to his lapsteel than your Martin or her lute—is an engaging, peculiar experience in life that is crazy fun to share with others. It’s not about excluding anyone—violinists, horn players, “guitarists” who don’t play “real metal”, people who golf in the sun while we develop calluses and scoliosis—but a chance to relate through something we often do separately. We hand off a little bit of our personal identities to one other, and we’re better off for it.
Second: By all means come up with new, useful names. We’ve seen that for governance and workflow styles both before and since “open source” entered the lexicon. “BDFL”, “GitHub Flow”, &c.
But I’m not yet convinced that specific practices, or anything like a broad, consensus-based community, has crystallized to the point of warranting a new umbrella term any more definite than “open source” in current parlance. I’ve met far more folks interested in raising a banner that others AYTBD will line up behind.
The most commonly proposed candidate is some take on “people on GitHub”, but there’s plenty of variation in practice with those tools. There are more than a few ways to use issues and pull requests. Hence CONTRIBUTING, pull request templates, whole repos full of “governance stuff”. There are also plenty of folks not using those features, including many who mostly work alone and happen to use GitHub for free storage or because they are asked to.
My instincts also advise skepticism. The more I talk to folks who want a label to recognize how they go about making software online, the more I find conversation falling back on negative definition. “The New Open Source” is GitHub. What does that mean? Not the Apache Foundation. Not the Free Software Foundation. Not a corporate sponsor. Not an academic paper. Not mailing lists. Not shell accounts. Not actual peer-to-peer Git, as Linus intended. Not the politics that gave us “Open Source”. But we’ve already accepted that the new set doesn’t know that history. They haven’t had reason to learn it. At least not yet.
Third, finally, most importantly: “Open Source” was politics. No doubt. No argument. But politics emerged because practical problems—licensing confusion, abuse, and related woes—affected lots of people, and you don’t get lots of people without politics. License forms proliferated. Mailing list flame wars raged. Legal departments of companies ready to draft more careful, rigorous license terms for corporate contributions didn’t know where to start. How could they be sure the community would accept them? Would they have to slay the local “IANAL, but …” dragon on every mailing list? There was a problem. “Open Source”, with definition, was an imperfect but serviceable solution.
Feedback
The scariest part of the “post-open source generation” thought pieces I read is that they legitimize ignorance of the pain software licensing used to cause and might cause again, both among developers and despite them, in business and the legal system. By slicing off a subset of people doing software who haven’t taken a licensing hit—in part thanks to what the Open Source Definition and the foundations more generally achieved before their time—they’ve isolated a point of view that doesn’t see the problem. I don’t mean to blame the journos. This is symptomatic of what’s going on online. But the coverage—simplified and exaggerated—is now feeding back. I fear the resulting distortion will create bountiful employment opportunities for my kind going forward.
As for the underlying disorder, I see two causes.
The first is the glorious flood of new programmers and new companies underserved by those, like me, who could warn of mistakes not to be repeated. When you code for you, or a small community of, say, the four friends on your modded game server, the licensing stakes are near zero. You’re highly unlikely to get sued, even if you, say, download and crack an obviously proprietary library or development tool. With some exceptions, the same is true in school, and in personal hacking projects. This gap beneath the cost of enforcement—too poor to pay, too expensive to find and sue, making too little to bother—covers even many freelancers and consultancies, whose clients may require little more than a boilerplate rep that IP in deliveries is clear. A successful shop outgrows that caliber of client despite itself.
The gap is also home to many start-ups, especially early-stage start-ups. Start-ups differ from contract shops in that, by definition, they aim to escape the gap—by piling liquid value in the company—as soon as humanly possible. Stories abound of fledgling companies “doing what they had to do” with proprietary inventions, data, code, packaged software, trade secrets, and so on to get off the ground. Then it came to light. Perhaps while pulling together IP schedules for a round. Perhaps once inside counsel got hired. Perhaps through the grapevine after a founder departure. God forbid, in due diligence for a potential exit. Or after acquisition, when the pencil pushers of the open-source compliance team at the acquiring megacorp got involved.
When you’re small enough, you’re just not worth the trouble. Nobody is going to land a patch in your public project to get folks trolled for infringing a patent. No sane former co-founder appearing repeatedly in your product’s Git repository log is going to come out of the woodwork for oodles of $0.00001 stock. And your CTO’s former employer is probably not going to knife you for the code she “open sourced” without legally binding permission a month before giving notice. You’re not worth the trouble. But if you succeed, you will be.
Even if you know this, you may still “feel” surprised after a long run in start-up land. I’ve seen “enterprisey” open-source compliance process as last straw for founders who walked on earn-outs to start something new. Entire careers and lifestyles can be made taking the “rocketship”—cough—up to the acquisition and sneaking back down the stairs to a new company. At least while the VC flows. It’s true that enterprises of a certain size exacerbate necessary compliance woes beyond their due measure. But failing to foresee predictable consequences isn’t punk rock; it’s willful ignorance.
Second, it is all kinds of easy to show and quote astronomical numbers of repositories, packages, patches, and so on. The more rigorous will follow up with some idea of how many of those what’s-its are even potentially viable for use outside the gap. But the more rigorous are few and far between. Are they oft-downloaded libraries with multiple contributors, or CJ’s CS-101 homework? Any LICENSE file? Are you counting my six dotfiles repos? This blog?
It’s necessary to mention these nameless, undifferentiated hordes when hawking wares. Up, to the right, or GTFO. It may not even be wrong to play a little fast and loose when you’re giving out free stuff of definite value. But registering for a free service is not registering for selective service to whatever cause cares to invoke you. Nobody gets an opt-out message when they cameo as a user-count chart pixel. It’s on those quoting astronomical user and code counts to show that the numbers represent what they say they represent, and that there are valuable needles to be found, cost effectively, in the haystack. Is a million repositories without LICENSE files a movement, or some combination of laziness and not knowing LICENSE is a thing? Are we just dumping the code we used to delete onto GitHub, ‘cause it’s free?
Scattershot
All of this must read very skeptical. But I do see a difference.
Software comes in smaller pieces, and we’re churning out lots of pieces, fast. We’ve gone from symphonies—Behold! It is Rails! You’ll need a book and screencasts!—to three-minute singles with pretty READMEs and maybe some code comments. Cross-platform interpreters and package managers have made much smaller, narrowly scoped software reusable. It’s free and easy(ish) to get a tiny project up, visible, packaged, and improvable by others. Most projects end up littering a bone yard of half-finished, ill-conceived, little remarked failures … but it costs little or nothing to leave the bones to bleach where they fell.
It all reminds me of indie music. The labels have always picked “stars” to lavish with writing workshops, production, payola, the whole package. And they were the only way to get music to stores. But lots of folks play, sing, write, start bands. And I think dirt cheap equipment, recording, and distribution have been far kinder to those folks than, say, a Taylor Swift on a 360 deal. Even a ragtag crop of not particularly photogenic players can make a hit, right up there with the major label acts. Artists with longevity, whether as performers or in other roles, also tend to have massive output, churning out lots, only some of which garners any attention. They just keep going, whether out of sheer determination to “make it” or because they just like doing what they do. It’s a home run contest, but they’ll pitch as many as you want.
Or compare it to start-up companies. Sometimes a good company, with a valuable technology, fails for all the wrong reasons. Market wasn’t ready. Somebody got sick. It goes on. But there are lots of little companies going at once, sometimes overlapping one another, even comically so. VCs make a portfolio, and if one in ten connects, they get what they hoped for. Serial entrepreneur is a near synonym for serial failure, but if you do a few companies, one might take off.
The trick to being a start-up company or indie act, as opposed to a megacorporation or a label star, is to stay in the game and keep costs of failure—which you can plan to suffer repeatedly—low. It’s hard to predict what you’re capable of doing that others will find enormously valuable. So you test lots of things, and you keep the cost of each test dirt cheap. GitHub and Travis and friends make creating a new repo for that npm package that probably won’t work out painless. You’re not going to have to rethink infrastructure—code hosting, bug tracking, e-mail distribution, releases—at any of the early stages before you know if the package has legs. If you reach a point where those tools don’t work for you—GitHub issues are notoriously rough on highly trafficked projects—you might have the contributors and resources to work it out.
Long story short: defer, defer, defer. If you can spend anything—time, money, nonrenewable personality and vitality—later, then do that. If you don’t make it that far, congratulations, you’ve saved the cost. What’s more, there’s no penalty for failure. GitHub will happily serve as your personal software shell mound, gratis. The community will praise you as prolific even if most of what you write goes nowhere. Just don’t put anything off that becomes unmanageably expensive or impossible to fix later. If you happen to make a hit, that’s going to cause problems.
So put your stuff on GitHub, but don’t dig an IP hole too deep to crawl out of if your project succeeds. Copy in a boilerplate LICENSE file, because folks who have to take IP seriously won’t go near your stuff without one. Keep good record of who contributes what and exercise basic caution about contributions that might belong to employers or otherwise violate corporate IP. If you end up with a successful project, you and your users will be very glad you did. Because open source licenses, as defined by OSI, are still the best tools we have for solving the software copyright problem.
You may not feel that pain yet. May your next project be so lucky!
Your thoughts and feedback are always welcome by e-mail.