In those late 20th century days of FOSS ascendancy, any adoption of FOSS by some organization, whether a business or a government, might be heralded loudly in headlines or comment sections or even by the organization PR departments themselves. Stencils proclaiming a company's "love" for Linux are the archetype from those days of trumpeting another entry into the big FOSS cuddle pile.
As time wore on, the cuddle pile got big and serious, more handshakes than hugs. It took on an air of The N-teenth Annual Plenary of Organizations That Love Linux Very Much Just Trust Us We Really Do Here's Some Money Can We Help Make Decisions About It Now.
So many people loved Linux, loved FOSS, that it sort of made me ask the age old question, What Is Love? and to wish the fateful wish, particularly about some of the bigger companies--ones with, let's say, a storied past, ones that came to the table very circuitously--baby, don't hurt me, don't hurt me no more.
Seriously, though, I began to wonder: What makes an organization a "FOSS" organization? When, especially this late in the game, is their use of FOSS, particularly participation so studied and self-promoting, something to be lauded, to be trusted, or even to be seen at all as notable?
Faced with an organization that wants to wrap itself in a FOSS banner, are there any standards to which we can hold it accountable beyond seeing that it uses some project[s] with FOSS licenses? Is it fair to hold every part of a large organization to the same standards? How do we allow for any kind of progress if an organization must pass at some point through a partial, incomplete state of FOSS participation? How do we guide ourselves and each other through that journey?
Wondering what might be fair to ask colleagues doing FOSS work in more than one large, slowly-moving, and mostly FOSS-indifferent organization, I came to something I think is fair to ask: To treat any use of proprietary software by a nominally FOSS organization as a bug.
Treating an organizational dependency as a bug puts that use on a level with other problems in a form we at least know how to talk about. It acknowledges a problem without necessarily pulling out all the stops, without losing all sense of proportion. It allows us to weigh decisions that lead to use of proprietary software with other costs and benefits. We don't have to make every use of proprietary software within our efforts release-critical, a record-scratch moment. But we should at least acknowledge it as an imperfection.
My hope is that we just might get past the point where we treat them, effectively and silently, as just WISHLIST WONTFIX, past the point of waving arms about software-shaming gatekeeping ideological purists when the subject even comes up. Then, if we can at least track them as bugs, even if we don't get any further with them, we're at least acknowledging and accounting for those choices.