The Curse of the Enterprise Version

Since I started working, together with my company, on the European project for digital sovereignty, I have begun to understand something I had previously only sensed: a disaster of epic proportions has fallen upon open source.

The enterprise version.

What happens is essentially this. You work on a piece of software capable, at least in appearance, of unifying something, centralising it, consolidating it. Software that does exactly what it is supposed to do: it takes a situation where previously you had, say, dozens of people managing tickets, each with their own departmental process, their own vocabulary, their own exceptions, their own local habits, and brings it into a coherent system.

You install our wonderful OSS software, and there you go: processes finally become comparable. Not necessarily identical in every detail, but at least they speak the same language. They use the same terminology, the same lifecycle, the same statuses, the same steps, the same general idea of “open”, “in progress”, “closed”, “rejected”, “assigned”, and so on.

In short: the software simplifies. It consolidates. It reduces the mess.

Good.

Then the enterprise world arrives.

“Can we have it like this, just multitenant?”

And that is where it happens: Manager A’s wife has become “multitenant”, and one of the new tenants is Manager B. It also works with husbands, of course: the model is perfectly gender-neutral. Anyway, what happens is that a spouse becomes multitenant, and suddenly there are two managers who can no longer stand the sight of each other.

At that point, by one of those mysterious unwritten laws of corporate organisation, marital multitenancy produces a technical request. The board managing the OSS roadmap receives a very serious request, drafted in the sacred language of management:

“For organisational reasons related to `<insert buzzword here>`, our huge company has made the strategic decision to adopt only software that operates in multitenant mode. We therefore wanted to know whether this functionality is already planned in your roadmap, or whether it could be considered for a future release.”

The correct answer would be:

“No, look, this is software that was created to simplify something, to eliminate useless differences in process, to consolidate procedures that were previously scattered, inconsistent, and departmental. Therefore, the fact that a manager’s spouse has become multitenant does not automatically imply that our application must become multitenant too.”

Because that is exactly the point. The software was born to reduce fragmentation, not to institutionalise it. It was born to remove exceptions, not to turn every exception into a feature.

It was born to say: “From now on, we all work within the same model”, not to say: “Let us create a separate universe for every little corporate prince, with his own rules, his own permissions, his own visibility settings, his own exceptions, his own tiny fiefdoms, and his sentimental traumas disguised as architectural requirements.”

But you cannot give that answer.

Because the company’s Cuckold Management cannot manage spousal multitenancy as it should, and therefore demands that the software reflect the same organisational pathology. If you do not give them the same multitenancy as their spouses, they threaten to “choose another product”.

And that sentence, in the enterprise world, is the equivalent of the red button.

At that point, the pressure begins. Someone starts saying that “the customer is important”. Someone else observes that “after all, multitenancy might be useful to others as well”. Someone else proposes “not closing the door to a possible architectural evolution”.

And so, little by little, software born to simplify is pushed into becoming the opposite of itself: a machine for replicating, in technical form, all the political, personal, and hierarchical dysfunctions of the company that wants to adopt it.

Because enterprise does not buy software.

It buys mirrors.

And every time Cuckold Management fails, every time two departments no longer cooperate because the antler rack is not part of the corporate dress code, something must become “multitenant”, so that those two departments can stop cooperating without having to admit it.

The result is that companies first adopt something in order to “simplify”. They like the OSS philosophy, they like this idea of small components that do little and do it well, they like the idea of software with a clear perimeter, software that does not pretend to solve the company’s entire organisational tragedy.

Then come the managers who are not part of Cuckold Management, or who suffer the consequences of it, and every time two departments cannot cooperate, a new requirement is born.

Not because the software is truly insufficient. Not because the technical problem had not been foreseen. But because someone inside the company does not have the political strength to impose a common procedure, a common vocabulary, a common responsibility.

And so the organisational fracture is turned into a feature. Two departments do not talk to each other? We need multitenancy. Two managers do not want to see the same data? We need multitenancy. Two processes should be unified, but nobody has the courage to say “from tomorrow, this is how we do it”? We need multitenancy.

So the software born to simplify begins to incorporate exactly what it was supposed to eliminate: exceptions, fiefdoms, artificial borders, separate procedures, different configurations, little local sovereignties disguised as architectural requirements.

And in the end you no longer have an elegant, modular, clean piece of open source software.

You have an org chart with a REST API.

"More Granular RBAC"

Another calamity that descends upon OSS is granular RBAC.

This, too, is ultimately a problem of Cuckold Management: at some point, because a spouse granted excessively high privileges to someone, it becomes necessary to ensure that nobody in the company can grant similar privileges without going through a Byzantine liturgy.

So, bang: granular RBAC suddenly becomes indispensable. But not a simple, human, comprehensible RBAC. No. An RBAC that interfaces with every RBAC system in the world, that talks to LDAP, Active Directory, SAML, OIDC, nested groups, inherited roles, claims invented by a consultant dead inside, and that therefore immediately becomes too complex for any small organisation that simply wanted to install some software and use it.

But that is not enough.

It must also be possible to ensure that the spouse cannot grant certain privileges. Or that they can grant them only in certain cases. Or that they can grant them only if department A does not get pissed off, because department B can do something that apparently falls within its remit, but in reality has a side-effect on someone else. And so the escalation begins.

Honestly, the answer would often be: “design your use cases properly”. Or: “how about checking how the fuck you design your internal processes?”

But reality is different: a department is led by a spouse irritated by the privilege escalation that certain spouses allow. And it is not a bug. It is the requirement.

Result: a request arrives to limit the action of viewing photographs if one is wearing a polka-dot tie, provided the person is not a Scorpio and does not belong to the “Finance” group, except for exceptions approved by Legal on Thursday morning. All of this, of course, is called the “principle of least privilege”.

Which would even be a sensible principle, if it were not used as an alibi to turn every corporate neurosis into a permissions matrix.

And so an OSS project born to have users and administrators finds itself implementing an entire AAA system: authentication, authorisation, accounting. An apparatus capable of deciding, user by user, role by role, department by department, which underpants they must be wearing when they click a certain button.

“The user can see the ticket, but not the comment, except if the comment is internal, but only if they belong to the Finance group, although not if the ticket was opened by Legal, unless there is an escalation approved by a deputy manager for the DACH region. A Sagittarius. Vegan. Have I already mentioned how good quinoa is for you?”

“Make it configurable.”

When software is simple, monolithic, and does one thing well, along comes the enterprise-version person asking for the most innocent thing in the world:

Pls, make this configurable.

It sounds like a reasonable request. After all, what does it cost? Just add a parameter. Just add an environment variable. Just expose a checkbox. Just avoid “hardcoding” certain choices.

The problem is that programs are often efficient precisely because they use intelligent specifications, and are built around those specifications. They are not fast by magic. They are fast because someone made reasonable assumptions, chose limits, and designed the software to work well within those limits.

But careful: since some spouse decided to get reconfigured by some colleague, now departments also want the software each their own damn way. Each with its own exception, its own parameter, its own different limit, its own local interpretation of reality.

Management, however, quite rightly, does not want to spend money on two pieces of software. It does not want two installations, two maintenance streams, two teams, two contracts, two separate incidents.

So?

So: “make it configurable.”

Thus, perhaps, someone had made a scalability choice starting from some rational assumption. They had established a maximum number, a maximum size, a maximum queue, a certain concurrency model. Not out of laziness, but because that constraint was a pillar of the software. It served to make it efficient. Therefore fast. Therefore predictable. Therefore, often, also secure.

And instead, no.

The corporate requirement arrives: “make it configurable.”

You built the whole thing for a maximum of 100 threads? No. That number must be configurable. Then they will put 13 billion threads in it, and complain that it is slow.

“Okay, we increased the number of threads just a little, but I did not expect something like this.”

Of course. Because for enterprise, “configurable” always means this: turning an architectural decision into a knob, handing it to someone who does not understand the consequences, and then opening a ticket when the knob is turned until it snaps off the dashboard.

One department uses an ERP. Another department uses a framework to do CRM. But we want one single piece of software. So?

“Make it configurable”: just put “ERP” or “CRM” in a parameter, and off you go.

There you have it: this is the disaster of “enterprise versions”. If you manage OSS software, do one thing. When you receive a request from someone at a large corporation, ask to speak to their Cuckold Management.

At least it will be entertaining.