Look, for instance, to the history of forks of Postgres to add new functionality.

Initial version often involve heavy surgery. Then the maintainers have to manually merge from upstream essentially forever. Manual merges are not fun, they are tedious, and they are prone to errors (in part because they are tedious).

Over time these companies get a better grip on the bare minimum they need from Postgres' internals and file PRs. The goal is for their changes to be an add-on instead of a code fork.

From what I understand, Postgres team rarely has any vested interest in being antagonistic to these companies. Google's business model pushes them toward being antagonistic to any such efforts. Which means cliqz is stuck managing a fork forever, and may even run into cat-and-mouse games.

The only way to win is not to play.

So I think they are defining whether a given API as "open" or not as whether it is callable from JavaScript? So they're only willing to edit the JavaScript code, but not the C++ code alongside it? (I am genuinely confused by the reasoning, questions are not rhetorical.)

An open API implies a certain intent of the author. If there is an open API to utilize some feature, that implies an expectation that others will use it and thus an expectation of a consistent interface version to version. If you're forced to go around monkey-patching the core framework, you can expect a moving target as there is no expectation of external users thus no motivation to maintain a consistent interface between versions.

So in this case, the core framework being exposed to javascript is evidence of the expectation of external users, thus it will likely not be a moving target. If you're modifying some software, you will greatly prefer programming to an API than not.

My interpretation is they're saying that Chromium's address bar code is complex deeply integrated with many other parts of the code-base (including many parts that interact with Google's search APIs). On the other hand, Firefox's address bar code exposes a simple javascript API. This means that making and maintaining custom modifications to the address bar is easier with Firefox.

Changing the search engine that powers the omnibox is different than changing the behaviour of the omnibox, which is kind of a lot when it comes to predictive search, predictive completion and a bucket of other things that I wish you could turn off (or can be turned off for a while before Google decides you shouldn't ever need or want to turn it off). It's a target with a huge amount of churn. I agree that Firefox is a more sane target as a developer.

The gp's parenthetical addresses what you call "predictive completion", only it uses the term "autocomplete".

It addresses changing the site that feeds it. It does not address changing the behavior.

When you decide to fork a project, a key concern is: how invasive are your changes going to be? This is a very large component of how easy or hard it will be to merge upstream changes in the future.

In this case, going with Chrome would mean very invade changes to enable exposing things the upstream specifically wants to keep private in their codebase. Firefox instead requires only well-delineated, minimally invasive changes because there is a nice clean boundary between UI code and engine code (which incidentally matches c++/js boundary, the languages themselves don’t matter much), which means their changes can be isolated to the UI layer, which in turn means a much cleaner path to merging upstream changes

I think, Open as in scriptable and documented. Chrome has many undocumented apis and most of it is in c++. Not everything is exposed to the webview area.

This reasoning makes sense to me. If you have a JS api, to me that implies a consistent and maintained interface. Modifying the internals seems like it could easily become deprecated or have to be completely different with a single wrong PR

That doesn't make any more sense. They seem to be conflating "it's been bound to the internal scripting system" with "open API"

Whether or not it's been bound to a scripting language does not make it any more or less "open" or stable (which is what they seem to actually be looking for - stability). They forked the code, everything is an "open API" at that point. There is no concept of open API vs. not when you're just talking about the source of a project.

Whether or not an internal API is stable is relevant. But that stability is independent of which language it's in, and the only way to determine that is to either look for author intent or history of the API. Just because it's currently exposed to JavaScript doesn't mean it's stable at all.

It does. For example Firefox made some features as API and declared interfaces, while Chrome didn't and left it as internal functions, which you cannot rely on, you cannot be sure that interface won't change.

Unless it's exported to 3rd parties it's an internal function. Just because it's JavaScript doesn't make it stable API.

And just because it's internal doesn't mean it's not an API.

I still don't know what that means. I run chromium. It has an address bar. I can change the search engine.

It means you can change how the address bar behaves in a complex fashion without changing the rest of the browser’s code.

Suppose you wanted a deeper change like it to automatically add .com .org etc to the address entered as long as that’s not a phishing website. Now you needed to maintain that patch going forward and reapply it to every new version of the base browser. That’s much safer if the address bar’s code is isolated from the rest of the browser.

If there's no real API, you have to patch things and diverge from master and then you face the problem that Chromium is under constant change that you most certainly can't keep up with, so either you chose to ignore all the work happening in Chromium and end up with a stale branch or you spend most of your time making your patch work with the latest changes.