41–50 of 50 posts
May I suggest using the Business Source License as the basis for this instead of the Openfare Commercial License? This way older versions of software would revert to FOSS instead of staying non-free forever.
I don't understand why you would want this to be in the code. That is just not compatible with how source code versioning works. If you, a contributor, want to change your funding preferences, you have to file a PR with the project? If you update your preferences, other branches of the same project can still have different preferences? If you fork a project, you have to put a meaningless commit in there to change fun…
> If you, a contributor, want to change your funding preferences, you have to file a PR with the project?
Yes, or, a bot could track your funding preferences from some repo and submit a PR for you. (Cryptographic verification permitting.)
> If you update your preferences, other branches of the same project can still have different preferences?
Yes but those other branches will be outdated and git will make that clear. Only the commit from which the software package is derived matters. Donation schemes are derived from software packages.
## Forking a project
Contributors could get a share of donations by proposing a change to a project's lock file via a pull request. Or they could fork and make a change. But their fork would have to stand on it's own as a software package.
Nice initiative. Any exploration into funding publicly used software is a good thing. May I suggest using the Business Source License as the basis for this instead of the Openfare Commercial License? This way older versions of software would revert to FOSS instead of staying non-free forever.
I need to think about it a bit more. And I'd like to hear more opinions on ideas like this.
Earlier quoted context omitted.
Thanks for moving the needle. Millions of companies use open source without contributing anything. I have a theory/daydream that: a) a new foundation could be created with a new licence, whose only purpose is to accept payments and distribute them, with max x% overhead b) that licence would stipulate that by paying a nominal yearly fee (e.g. 10 hours average developer cost in your country) you would get all-you-can-e…
I want to be optimistic about this, but I don't think the result would be that every company would sign up for this. Rather, every company would implement their own 10-liner library for adding ANSI color codes to terminal output. The whole system of smallish dependencies you add in on an as-needed basis only works when the cost of adding them (INCLUDING the transaction costs, the cost of dev hours spend on convincing…
I think this gets to the heart of the matter. The goal with OpenFare (for non-FOSS) is to minimize this overhead cost. I believe that it can be minimized to a point where it is negligible. For FOSS it is already negligible. The method for minimizing that cost is to make a predictable pattern familiar and ubiquitous.
> had better respond quickly to security vulnerabilities and feature requests
That depends on the deal. If you buy software for $.01 what do you expect beyond your expectations had you paid nothing? Software support can't be assumed just because money is trading hands.
https://snowdrift.coop/ https://github.com/fossjobs/fossjobs/wiki/resources
Earlier quoted context omitted.
I want to be optimistic about this, but I don't think the result would be that every company would sign up for this. Rather, every company would implement their own 10-liner library for adding ANSI color codes to terminal output. The whole system of smallish dependencies you add in on an as-needed basis only works when the cost of adding them (INCLUDING the transaction costs, the cost of dev hours spend on convincing…
> the cost of adding them (INCLUDING the transaction costs, the cost of dev hours spend on convincing the procurement dept, etc etc etc) is cheaper than the cost in dev hours I think this gets to the heart of the matter. The goal with OpenFare (for non-FOSS) is to minimize this overhead cost. I believe that it can be minimized to a point where it is negligible. For FOSS it is already negligible. The method for minimi…
The "no warranty, express or implied" is an important part of the licence.
1. It better captures the project dynamics. Sometimes the author and maintainers don't do much work or don't need the money at the moment.
2. It makes it easier to ask for money.
3. It may also solve the unclaimed donations problem. See for example https://liberapay.com/explore/pledges
I would love to see this supported by projects such as librepay: 1. It better captures the project dynamics. Sometimes the author and maintainers don't do much work or don't need the money at the moment. 2. It makes it easier to ask for money. 3. It may also solve the unclaimed donations problem. See for example https://liberapay.com/explore/pledges
I would love to see this supported by projects such as librepay: 1. It better captures the project dynamics. Sometimes the author and maintainers don't do much work or don't need the money at the moment. 2. It makes it easier to ask for money. 3. It may also solve the unclaimed donations problem. See for example https://liberapay.com/explore/pledges
I haven't heard about librepay before, thanks for letting me know. I'll take a look!
Since my current job would have been much harder without FOSS, during the pandemic I made it a habit of drinking coffee at home and sending my fav developer of the month equivalent of one overpriced cappuccino.
I don't understand why you would want this to be in the code. That is just not compatible with how source code versioning works. If you, a contributor, want to change your funding preferences, you have to file a PR with the project? If you update your preferences, other branches of the same project can still have different preferences? If you fork a project, you have to put a meaningless commit in there to change fun…
I'm not sure it's the perfect solution, for reasons that relate mostly to the (necessary, useful) ability to modify and adjust rewards on a long-term and after-the-fact timescale, but I'll offer one reason why this could be a good idea: It codifies the social side of enterprise ownership. Not just for the participants in the enterprise itself, but for potential investors, users of the service, collaborators and busin…