Notices by Jens Finkhäuser (jens@social.finkhaeuser.de)

@benjamineskola @drew Yeah.

Part of me was all like "but these range from dangerous to the world to probably just a bit fucked up", but the "weird little guys" part really underlines that the difference is about 98% money/power.

The scale of the threat doesn't change the nature of the threat.

I mean, if I were to maintain such a list, which I deliberately don't, I'd have some additions. But that's between me and my sarcastic half, I think.

@notclacke Yes, hahahaha, adding a third programming language to C++ and JavaScript surely helps reducing complexity!

(The sarcasm isn't aimed at you.)

Let's hypothesize a little. The three "culprits" in this complexity all happened in the last 20 years: new JavaScript VMs that can be leveraged. Isolating tabs, but allowing some data sharing between them. Local storage for websites.

So we can extrapolate grandly and claim that a code base has a chance of remaining relatively pristine for about 20/3 ~= 7 years.

Incremental changes fall into two categories: they either have *no* direct contact with these subsystems, or they do. If they have...

... none, we can ignore them. This is also going to be the vast majority of incremental changes.

So if we're asking about incremental changes related to these subsystems, you can probably handwave the incremental cost of such a change on the grown codebase to be twice that of a clean code base. Any more realistic factor F is fine, really, I'm pulling the "twice" out of my arse^Wexperience.

So we have N * T * F for the cost of those changes on the grown code base vs. N * T for the clean one.

Now a big change rolls around. Making that change fast is going to take C1 time. Making that change such that the code base remains reasonably clean will take C2 time, where C2 > C1.

What we're really asking is this:

Is (N * T * F) - (N * T) larger or smaller than (C2 - C1)? That is, is the cost of doing things well higher than the difference in TCO that stems from doing things well vs. doing things fast?

Hey, look, I can put this in business-y terms after all.

I can't answer this for the...

Some twenty years ago, I learned that the Mozilla/Firefox code base used various different and incompatible string encodings, and one had to constantly convert back and forth between them.

In the last weeks, I've been digging around the code base again for reasons I shall write about at some point (hopefully soon), and realized that this has actually become worse.

I'm currently at about 4-5 different encodings *that I need to know about for my purposes*.

Meanwhile, the coding style (also just limited to what I need to know about) varies wildly between subsystems; some of it is relatively intuitive, while other parts... well.

The worst IMHO are the parts that suffer from "we want to do Java interfaces, but we have C++". Here you find three or four levels of indirection to allow for some derived object to define some kind of functionality, only to discover that it's much the same between all implementations.

If you discover them all, because...

... some implementations are instanciated using macro expansion, which makes it hard to grep through a code base.

I write this not so much to complain. This code base has grown for decades. I would not expect anything significantly simpler.

However, when people sometimes write "Firefox is too big and complex to fork", or "nobody has the resources to build a browser", it adds some perspective.

It's not that a browser *has* to do things this way. It *is* possible to be more consistent, reduce complexity, and still do the same thing.

Is cleaning this up feasible? Unlikely. The dependencies that one piece of code has on the behaviour of another is probably too complex to track. I wouldn't want to do that.

Is a greenfield rewrite...

... feasible?

Yes, absolutely.

Would that take long? Yes, but not as long as cleaning things up.

This is where business oriented thinking now asks "what is the benefit of this investment?", and the answer isn't tangible in business terms. There is no way that sinking years of development into something that may reach parity with something that already exists has a good ROI.

But this thinking is mired in something that, well, while it isn't *exactly* the sunk cost fallacy, it feels very...

... similar.

The cost/benefit analysis here requires that the cost/benefit of an incremental change is compared to the cost/benefit of a rewrite, and here the incremental change will always win. This essentially anchors the thinking in sunk costs.

What it cannot do is ask this: if the rewrite existed, how much lower would the cost/benefit be of incremental changes based on that compared to incremental changes based on the current code base?

Cumulatively, over the projected lifetime of a...

... software, that's the interesting part.

But it's so hard to quantify that the question is rarely explored.

(Also, let's assume the awesome new version *also* grows organically, so the "lifetime" must be capped at "while it is still a reasonably clean code base", which makes the problem even harder to grasp).

The TL;DR is, we won't get many new browser engines, not because it's impossible, but because people with control over purse strings rarely look a few decades into the future.

@skinnylatte warm tea.

@mwl Not a troll question: what IS the point or purpose of MIT/BSD licenses?

I ask because as @lproven wrote, it seems like frustratingly offensive language aside, the point about copyleft is, well, why copyleft exists.

@mwl @lproven Ok.

So I'm really not trying to start an argument. But consider that in the sense of "a system is what a system does", the author seems to understand MIT/BSD licenses quite well.

Which is to say, it's perhaps less of a question of understanding, and more of a question of which effect carries more value (good or bad) for you.

@mwl @lproven No, the difference being whether widespread high quality software is more important to you, or guarantees (to the degree possible) that free access to software related human knowledge is preserved.

@conservancy nope. Fail.

The aim of gen AI is to move the means of production from devs to model owners. This undermines FOSS more thoroughly than any Embrace Extend Extinguish attempt to date.

@bkuhn Stalemate?

It's an arms race, and one side has the funding for it. Hint: it's not us.

So forgive me if I judge success differently. Much of what I see are compromises that set up the next battle in a weaker position.

I understand that back in the day when free software and open source started, the libertarian positions it holds were adopted.

We had privileged white boys complaining about having their privilege reduced. Yes, with enough vision to see liberation for everyone on the...

@bkuhn ... horizon. But not enough self-awareness to factor privilege into things.

Which is why the freedoms value individual choices much more highly than the common good. The logic is, quite literally, "I need liberties so I can help others", not "the rights of the unprivileged need to be strengthened".

It's missing the equivalent zero'th law of robotics. And fuck, it shows.

@bkuhn This isn't capitalism's fault. There is a lot of fault in capitalism, sure.

But this is the FLOSS movement's own failure. It's my failure as well. I used to believe that shit. Feels good to picture oneself as a Robin Hood character.

So quelle surprise, but there are libertarians out there who do not value the commons, and we've let them dominate the conversation. Thinking they were some of us. But they're robber barons, arguing for their liberties in order to rob.

So any position...