April 18, 2019

Diglossia limits on software success, hidden in plain sight

diglossia, n.

The use of two divergent varieties of the same language for different societal functions.

We talk about success in software in two different ways. We should recognize what we’re doing, and the consequences.

In the business frame, we speak of profit, payment, customers, finance, companies, services, management, and private gain. In the other frame, which I’ll dub “community” with big scare quotes, we speak of sustainability, donations, adopters, support, foundations, infrastructure, governance, and public service. Corresponding terms convey the same fundamental ideas. But there are equally fundamental, implicit differences in the choice of one way to speak or the other.

When we frame developers’ needs in community terms, we impose an implicit limit on reasonable worldly expectation. We expect community developers, even well known ones, to scrounge, even to suffer, just as we expect artists, even famous ones, to struggle and starve. Conversely, when we frame developers’ needs in business terms, we put a cap on cool. We expect business programmers, even accomplished ones, to spend a lot of time writing mundane business logic for mundane business needs, just as we expect commercial illustrators, even established ones, to draw lots of plump fast food, glistening soda bottles, and smiling conventional beauties.

The usual consequences of either-or distinction—misclassification and oversimplification—are in full effect. Open developers trying to make ends meet bristle when others, especially businesses, “community” them. They learn that those terms severely complicate, and forestall, achievement of their goals. Entrepreneurial software types, for their part, bristle at heavy-handed business talk. They learn that those terms endlessly undermine, and cripple, their ability to express and achieve greater purpose through their ventures.

As far as I’m aware, there is no viable, middle vocabulary for developers who intermingle craft and worldly success. Attempts to construct one reek of marketing bullshit or try-hard gunner-ism. Instinctively, we presume that those mixing terms, or inventing new ones, try to seem what they’re not.

If you find yourself consistently playing out one archetype or the other, or balancing both with clear separation, two distinct categories can reinforce a pleasant feeling of compartmentalized concerns, grass-is-greener, yin and yang. Some programmers rush home from work to churn out open source where none of the boss’s rules apply. Many freelancers take comfort in offices that look and feel very different from home, even if the office is actually just a separate room in the house.

We can take similar comfort in change of linguistic scenery. Work looks like work, sounds like work, and feels like work. Home looks like home, sounds like home, and feels like home. Thanks in part to their distinct vocabularies, open and closed look, sound, and feel distinct, and for some, that’s a feeling of comfort, that all is right in the software world. Money, expression, hierarchy, and anarchy all stay where they belong.

But people differ in their tolerance, and desire, for life in two spheres.

Some want nothing more than a stable day job to finance freedom during nights, weekends, and off time. Some of those believe they could never make the art they want mixing art and commerce. Work-life-balance is the elusive goal, occupying an entire creative life.

Some have to make art the whole of life. Some of those believe they could never make what they want ceding half their waking hours to irrelevant labor, or without the inspiring constraints of a mass audience. Work-life balance makes no sense because ideally, they were never dissolved to begin with.

Two competing psychological needs, attempting to occupy the same linguistic space. One seeks to keep the line between business and community sharp, the other to blur and erase it. Some want money out of open source, to avoid “working” its vibe, while others rail against the anti-money allergy because it’s holding them down.

I have more confidence than I usually would in analysis this general because it correlates so well to my other profession. Among lawyers, there are those who hang shingles, rise in firms, and otherwise make their stand in private practice. There are those who go in-house, join foundations, and take public posts. Neither camp holds any monopoly on entrepreneurship, or on civic-mindedness.

But reading Kate Downing, another open licensing specialist in private practice, I’m struck by how little surprised I was to see her recoil, and hard, from the community framing of a recently announced money-for-open-source initiative. Quoting Kate, who said it far better than I could have:

I have deep misgivings about a system that has no interest in empowering developers to simply make a living by working on open source software, and instead believes that developers should want nothing more and expect nothing more other than to join giant corporations as salarymen.

Compare Bruce Perens, responding to Luis Villa:

What does an economically viable open source look like?

My usual answer for this is that if you have to ask how you’re going to make money, you’re the wrong person to make Open Source.

My response to Bruce’s message, and my takeaway here more generally, is that the two predilections, in their archetypal, absolute forms, aren’t going to reconcile. Neither is there any sign that one will break away, to dominate the other. Big Tech is getting bigger, stacking up ever higher head counts, while at the same time remote companies, contractor swarms, part-time work, and all that’s dubbed the “gig economy”—scare quotes again—flourish and grow. By all signs, both lifestyles are stuck cohabitating a common industry for the foreseeable future.

I’m not sure, in all wisdom, that either should want anything else. Excluding one or the other, from open software or any other broad-based effort, is leaving a ton of human potential on the table. When optimization costs that much, it’s almost never worthwhile.

All that said, I’m not sure I know what to do about the trouble our words are causing us. I can point the problem out. I can push for more neutrality, and less narrative, in the understanding of business-speak and community-speak.

In the end, perhaps there’s nothing to be done. We’ll simply keep colliding, linguistically, socially, and financially, until appreciation for the diversity of open software’s present, and how to leverage it, becomes more evenly distributed.