>> law, technology, and the space between

All content by Kyle E. Mitchell, who is not your lawyer.

You can subscribe via RSS/Atom or e-mail and browse other blogs.

Locked-In Customers Anonymousstop buying software from assholes

One of the points that sold open source to business was freedom from predatory vendor lock-in. Go with open source, you’ll never see another “not renewing, call sales” letter for critical code ever again. Fast forward twenty or forty years, depending on how you count, and the open source faithful still bash software vendors, at least the ones they don’t work for. Especially Oracle.

But I’ve noticed that more often than not, it’s no longer “predatory vendor lock-in”. It’s just “vendor lock-in”, or, frankly, just “vendor”, full stop. With “vendor”, the “lock-in” goes without saying. And “vendor” implies “predatory”, as a matter of course.

But no, it doesn’t.

If every form of dependence presses your panic button, if the only way you know to play with others is to own what they do or get it all for free, if behind any license deal lurks an abusive relationship in disguise, you need to stop buying software from assholes. Stop working for companies that habitually do. You’re feeding the sharks. The software world isn’t quite that cruel, and you ought to know it.

Try a boutique vendor. Or even a larger private shop. Someplace where you can get to know a dev or a manager before anyone says “lead” behind your back. Do your homework, of course. Be sure their finance doesn’t condemn them to short-termist managers, “power closer” hobgoblins, and panic-inducing, eat-the-seed-grain sales targets, in the normal case. Then make a deal.

Negotiate for source code from the get-go. Happens all the time. Lock in renewal rights and price protections. Basically de rigeur at this point. Get a broad license that kicks in if they end-of-life you. Generally unobjectionable. Price out some consulting hours, and involve their development people as collaborators, not just “ticket and fix it” support. Often welcome, and if not, a big red flag. Buy from a team that wants to be part of yours. Whether they ship binaries, source code, or SaaS.

DHH may or may not be crazy, but 37 Signals isn’t going to shank you. Rich won’t be selling Cognitect to Bain, Blackstone, or the Borg anytime soon. Mike Perham isn’t going to decide great ain’t good enough, take a giant check from a16z, and set Sidekiq off like a rocket ship, vaporizing your project on the launch pad. All those companies are made of the kinds of people you’d probably love to work with, but can’t realistically hire for yourself. Especially if you work at a large, lumbering enterprise with broken, shellshocked people in a thousand impinging departments and bad blood curdling with each passing nonrenewal deadline.

If you reach out even to good, earnest companies with one hand on your sixgun and the other on a long knife, fight or flight is what you’ll get on the other side, whether they were out to suck your blood or not. It’s negotiation 101. If either side goes in hot, conflict escalates. It takes two, or a big leap of faith on one side, to wind things back down again. But go in ready to play team ball, where not just code and money, but also ideas cross the company line, and you might just make each other money. Talk through a contract, instead of passing off to the shove-it-down-their-throats department, and the time to close just might surprise you, too. So will the oddly positive vibes at project start, with nobody limping in from the negotiation process thinking they just got shafted somewhere in fine print.

That’s not to say that you should run out and find a paid alternative to every free or open thing you’re running now. Of course not. But if the question is “Do we insist on everything open, or do we do deals with people who charge for good work?”, the answer is “Why not both?” and “It depends, so we better get good at telling the difference.”

100% permissive open source, with the occasional sprinkling of paid consulting or support, 100% of the time, is often glaringly suboptimal. Absolute “independence” is only as deep as your own self-deception, which you’ll find out when you hit a problem or an upgrade, and reality reasserts itself. That’s happened quite a bit in the last few years.

The lack of a people connection in parallel with the code also cuts both ways. Your people might contribute some unplanned feat of inspiration responsive to your business or customer needs, but it’s highly unlikely any of your dependencies, which may or may not know you exist, will do so by chance.

Likewise insisting that if it doesn’t have a million dollar company, a patent warranty, and a 24/7 support team of well mannered Indians behind it, you can’t take it seriously or put it in your stack. That’s also too simple, and likewise divorced from observable reality. One of the problems those of us working on “sustainability” with add-ons like warranties, best practices checklists, documentation, and the like see is that pitching these things reminds companies that they haven’t had them yet, and have been getting away with it fine.

On the commercial side, you’ll also sometimes hit vendors who mash “proprietary” and all the other “enterprise-grade” buttons as hard as they can, with apparently little verve for the software, service, or support they nominally sell. Fall for one of these, you’ll soon realize how government software ends up the way it is, and that you are now part of the problem.

In the not too distant past, we enjoyed a much richer vocabulary for these kinds of issues. A vocabulary that expressed the underlying tension with more nuance.

Gentlemen and would-be gentlemen of the American revolutionary period, for example, were entreated to maintain their independence by subsisting on rents from land, rather than on involvement in trades, professions, or business. In times of financial distress, gentlemen might stoop to a learned profession, such as law, to reestablish their means. A few new gentlemen, Ben Franklin included, worked their way up this way, until they could “cash out” and buy their base. But they were second rank, in part because gentile status and privilege were rationalized by the “disinterestedness” that personal and financial remove from petty commerce implied. Unsullied by business, landed gentlemen could participate in politics, science, art, and the stewardship of society, all for their own sakes. They could patronize tradesman and artisans to do work that common exigencies wouldn’t bear, and felt a social responsibility to do so, and to show they were doing so.

All the same, in designing a new government and a new constitution, the leading lights and commercial kingpins of the colonies never aimed to make gentlemen in office absolutely independent, like divine-right kings of old. They’d had enough of that. So quite to the contrary, they sought very consciously to design the dependencies of men and institutions vested with power, believing, to a point, that dependencies determined behavior. Behavior like governance.

This was hardly surprising. While gentlemen were the least constrained by dependence, they sat at the pinnacle of a society structured by dependence, and of an explicit, formalized, pre-egalitarian kind rarely acknowledged today. “Disinterested” didn’t mean indifferent, but what we might mean today by “without vested interest” or “unconflicted”. A good society was a society of rational, functional personal and institutional dependencies, not a society of economic free agents unmoored from each other and the whole, free to spite the common weal as self-sovereign individuals.

The moral of this history for software is simple: Binary, yes-or-no independence, a liberty apart from the main, is a theoretical construct, an ideological fiction, a power fantasy. We are interdependent, our projects are interdependent, and our companies are interdependent. That does not mean we aren’t free.

Freedom lies in the choice and maintenance of our dependencies. Our dependencies partly determine us, but we partly determine them. Not just in the code or other building blocks we choose, but far more importantly, in our relationships with others who make them.

The right dependence can enrich our work and our lives more than any listless autonomy, any cleanly modeled anomie. But we can’t embrace such opportunities without recognizing them. We’re loathe to do so when we let moral husks of men shock us into believing that only sociopaths run software companies, that collaboration among companies backstopped by legal permission must be war, and only collaboration among individuals, and fellow nerds at that, can be life-affirming, prosocial, and good.

Predatory vendor lock-in is a serious bummer. But not every vendor is predatory, and not every relationship is lion-meets-gazelle. Unfortunately, it’s perfectly possible to make a whole career in dark, lucrative corners where those grim generalities more or less hold. Especially at the enterprise pinnacles, where free as in beer is very welcome, but the values of open source still do not and cannot belong.

Locked-in brothers and sisters, take heart. Raise your expectations and keep hope. Don’t ingrain your disappointment and trauma. Maybe bumps, bruises, and scars are the price of your paycheck and your equity package. But that’s not software as a whole.

Your thoughts and feedback are always welcome by e-mail.

back to topedit on GitHubrevision history