3 ms·
It’s simple, FOSS projects are an act of charity to the community. Trying to make money from ”the project itself” creates misaligned incentives, as the maintai
by gitgud 3y ago
It’s simple, FOSS projects are an act of charity to the community.
Trying to make money from ”the project itself” creates misaligned incentives, as the maintainers are trying to extract value/funnel users to pay. Whereas the community is attracted towards FOSS in order to not pay…
Adding support and maintenance fees also creates this misalignment of incentives. The community wants easier and simpler configuration, debugging etc… but the maintainers get support work if the project is difficult to configure, so naturally it’s not in their interest make the project easy to fix/configure…
The FOSS project itself needs a different commercial product to support its development. The best projects with aligned incentives are FOSS frameworks and libraries that a company needs in their commercial product…
- kjok 3y ago> Whereas the community is attracted towards FOSS in order to not pay… Community comes together to co-create value for everybody, which in itself is some sort of tangible currency. But a very high number of FOSS libraries/packages DO NOT have a community. How do you believe such projects must be sustained?
- gitgud 3y ago> ”Community comes together to co-create value for everybody, which in itself is some sort of tangible currency.” In this case the community is volunteering time/resources to the project. In my experience it takes a lot of management to pull this off, with PR reviews, discussions, design road maps… etc > ”But a very high number of FOSS libraries/packages DO NOT have a community. How do you believe such projects must be sustained?” Without a community to volunteer effort, the creators need to donate. Either they have a commercial product that funds the FOSS project. Or more commonly, a highly paid software engineer gives back to the community as philanthropy
- ezekg 3y ago> Adding support and maintenance fees also creates this misalignment of incentives. The community wants easier and simpler configuration, debugging etc… but the maintainers get support work if the project is difficult to configure, so naturally it’s not in their interest make the project easy to fix/configure… In my experience, if the community really wants something, they'll build it and open a pull request. The company behind the project isn't required to make things easier to e.g. self-host. Not accepting PRs that do make things easier for the community but may hurt upsell incentives otoh would be very bad, I agree with that.