Comment by echelon | Hacker News Reader

Comment by echelon | Hacker News Reader

Parent Full thread

The "Fair Source" [1] and "Fair Code" [2] licenses are sustainable and user-friendly.

Imagine if Docker the company could charge AWS and Google for their use of their technology.

Imagine if Redis, Elastic, and so many other technologies could.

Modern database companies will typically dual license their work so they don't have their lunch eaten. I've done it for some of my own work [3].

You want your customers to have freedom, but you don't want massive companies coming in and ripping you off. You'd also like to provide a "easy path" for payments that sustain the engineering, but not require your users to be bound to you.

"OSI-approved" Open Source is an industry co-opt of labor. Amazon and Google benefit immensely with an ecosystem of things they can offer, but they in turn give you zero of the AWS/GCP code base.

Hyperscalers are miles of crust around an open source interior. They charge and make millions off of the free labor of open source.

I think we need a new type of license that requires that the companies using the license must make their entire operational codebases available.

[1] https://fair.io/licenses/

[2] https://faircode.io/

[3] https://github.com/storytold/artcraft/blob/main/LICENSE.md

Charging companies for software is as old as computers itself. We don't have to imagine.

The idea of not compensating for software took hold in the 2000s, both with engineers and consumers (remember when users scoffed at 99 cent apps?)

Big tech companies saw this as an opportunity to build proprietary value-add systems around open source, but not make those systems in turn open. As they scaled, it became impossible to compete. You're not paying Redis for Redis. You're paying AWS or Google.

> The idea of not compensating for software took hold in the 2000s, both with engineers and consumers (remember when users scoffed at 99 cent apps?)

Part of that was that the platform churn costs were a new thing for developers that needed to be priced in now. In the "old world" aka Windows, application developers didn't need to do much, if any at all, work to keep their applications working with new OS versions. DOS applications could be run up until and including Windows 7 x32 - that meant in the most ridiculous case about 42 years of life time (first release of DOS was 1981, end of life for Win 7 ESU was 2023). As an application developer, you could get away with selling a piece of software once and then just provide bug fixes if needed, and it's reasonably possible to maintain extremely old software even on modern Windows - AFAIK (but never tried it), Visual Basic 6 (!!!) still runs on Windows 11 and can be used to compile old software.

In contrast to this, with both major mobile platforms (Android and iOS) as an app developer you have to deal with constant churn that the OS developer forces upon you, and application stores make it impossible to even release bugfixes for platforms older than the OS developer deems worthy to support - for Google Play Store, that's Android 12 (released in 2021) [1], for iOS the situation is a bit better but still a PITA [2].

[1] https://developer.android.com/google/play/requirements/targe...

[2] https://news.ycombinator.com/item?id=44222561

> As they scaled, it became impossible to compete.

To compete at offering infrastructure maybe, but what I would like is more capability to build solutions.

And I think that today one has much more open-source technologies that one can deploy with modest efforts, so I see progress, even if some big players take advantage of people that don't want or are not capable to make even modest efforts.

> Imagine if Docker the company could charge AWS and Google for their use of their technology.

An "issue" is that Docker these days mostly builds on open standards and has well documented APIs. Open infrastructure like this has only limited vendor lock-in.

Building a docker daemon compatible service is not trivial but was already mostly done with podman. It is compatible to the extent that the official docker cli mostly works with it oob (having implemented the basic Docker HTTP API endpoints too). AWS/GCP could almost certainly afford to build a "podman" too, instead of licensing Docked.

This is not meant to defend the hyperscalers themselves but should maybe out approaches like this in perspective. Docker got among other things large because it was free, monetizing after that is hard (see also Elasticsearch/Redis and the immediate forks).

> Imagine if Docker the company could charge AWS and Google for their use of their technology.

I can't imagine. Tell me one software project used in AWS/GCP that Amazon/Google pay for. Not donations (like for Linux), but PAID for.

Docker started as a wrapper over LXC, Amazon has enough developers to implement that in a month.

> Imagine if Docker the company could charge AWS and Google for their use of their technology.

The technology on which Docker is based, Linux containers, was developed by Google engineers for Borg, and later Docker adopted it when it pivoted away from LXC (an IBM technology).

Reply on news.ycombinator.com