[SpicyLemonZest]

I wouldn't really say there's a risk. It's just inferior to an open core model in most cases. The private license deters independent contributions, the AGPL license prevents small businesses who can't yet afford your system from using it, and large corporations don't care at all that your full source code is publicly available.

[ezekg]

I would argue that fair core is, in a lot of cases (not all ofc), superior in the long run to open core, because under fair core, the entire code base eventually becomes open source, unlike open core where commercial features remain proprietary/closed indefinitely. There are pros and cons of both that need to be weighed ofc, but I personally really like fair core.

(Disclaimer: I contributed to the FCL: https://fcl.dev)

[SpicyLemonZest]

I like the idea in principle after reading through it - it lines up with a lot of conventional wisdom about how fast software becomes commoditized. But there's a lot of practical aspects of commercial development that I'm not sure really work when your commits go out to the public. How would an FCL codebase, for example:

* Merge a bad change which makes the project worse, because it'll unblock a contract that stands to make your company a lot of money.

* Iterate on support for a proprietary workload from one of your customers, who has not licensed that workload publicly and indeed may consider it a trade secret.

[wmf]

1. Just do it and don't apologize to freeloaders.

2. Don't name customers in commits.

[davidgerard]

> AGPL license prevents small businesses who can't yet afford your system from using it

what? This sentence appears to be literally untrue. In what way?