Mechanism to really incentivise collaboration

[leventov]

https://fluence.network/ says:

Current software model favors data and value extraction, so the largest platforms earn the highest returns, hire top developers and perpetuate dominance. Fluence turns competition into collaboration by enabling global developer community to compose components, products, and features.

Also here:

These new business models are based on digital licensing for the applications’ usage over the network and are possible due to the consensus layer which tracks the financial relationships of the service providers and users. This economic opportunity complements the open, customizable and composable Fluence architecture and will help accelerate software innovation.

It doesn't seem to me that this idea of rewards based on software usage incentivises collaboration. Authors of applications are incentivized to re-implement (or just re-label) all their dependencies so that no reward "leaves" their application. If the application is popular, there is enough economic sense to do this. This is exactly what Amazon is doing today: they are re-implementing systems like Redis from scratch, only conforming to the Redis API so that they don't have any licensing issues with Redis Labs.

Another problem of distributed systems development (I think) is excessive focus on foundations (databases, distributed log systems, Big Data engines) because everyone wants to be "close to the root of the computational food chain". On the other hand, I think that not enough people work on open-source distributed applications (e-mail servers, search engines, recommendation engines, social applications, etc.) E. g. Brave search is not open-source and I highly doubt that Neeva will be.

An additional interesting question will arise when there will be AI sufficiently capable to write their own code. Who will be incentivized, AIs themselves or the creators of those AIs?

Who and how will be incentivised if an open-source project is authored not by an entity or a single individual but through open-source collaboration? How do we properly weigh the contributions of developers, issue reporters, CI systems, and static analysis bots?

I think that when we talk about distributed computation and programming, financially incentivising individuals through licences or API calls is fundamentally misguided if we truly want to catalyze collaboration towards better systems. It's also losing ground in the face of automatic AI programming and the contribution of other systems that improve our code one way or another (e. g. free CI services, and even Github itself as a convenient web service).

Wikipedia model

One alternative is the Wikipedia model. Editors of Wikipedia are not incentivized by anything except the contribution to good articles themselves. For readers of Wikipedia, the authors are anonymous 99.9% of the time (although within the Wikipedia community of editors, having many edits is an internal badge of honour).

Maybe to truly foster transformative collaboration, we shouldn't incentivise anything except the betterment of the applications which run on the web of distributed nodes.

[evgenyponomarev]

Your concern is valid but the devil is in the details. Fluence approach enables to unsilo the siloed cloud ecosystem similarly to how the open Web protocol democratized access to the information. Fluence doesn't solve all open-source related issues but brings a new revenue stream for useful code and empowers the collaboration around the cloud/backend services and network primitives.

It is important to think about the future we are trying to create and if the "self re-licensing" strategy fits there. Developers want to do less work and pay less, but if they have a choice they usually choose the former and the cloud existence has proven that fact. So if anyone trusted provides you managed service that does what you need so you can just use it as a part of your application, you probably will take it. Especially if you know that you will be able to seamlessly migrate to another service provider without losing time and data.

Fluence is aiming to build this kind of future. Where developers can have this choice of self-hosting (with more effort) or relying on others (with less effort) but to be able to make a change at any moment. So they are free from vendor lock-in. And because many people choose convenience over heavily optimized costs, author rewards are not in danger.

The next point is where those "self re-licensed" services live. Technically you can always re-license all dependencies to avoid author reward going anywhere besides you. But then you lose the flexibility of hosting these services in the network because nodes now have to trust code coming from you, authored by you, which workload is less predictable compared to well-known sources used by the majority of other people. So you will be forced to host your application on nodes maintained by you, which adds frictions.

Finally, yes, AWS can re-license Redis and everything else under their own name and become a provider on the Fluence network and use all their marketing power to promote their services. So that becomes a competition between AWS ability to attract customers versus the original authors. But the difference with the current state of things is that with Fluence users have a choice so they can compose a service coming from AWS with a service coming from another author, migrate from AWS-authored services at any moment, or run AWS-authored service on a different host.