rndhouse

10 ms·

31.
by rndhouse 5y ago
That's great to hear! Yes, we've wondered across the same sort of idea with your "DONATIONS.txt" file. I post updates when I can to the Matrix chatroom: #openfare:matrix.org But feel free to follow along however!
32.
by rndhouse 5y ago
Sponsorship and donations are the popularity driven funding mechanisms. I want to fund the unpopular long tail of software maintainers (like the log4j guys who were not well known before the incident). I want to fund maintainers based on wh
33.
by rndhouse 5y ago
Honestly, your comment is the most useful I've had so far. I agree with what you've said. I don't expect any company to pay anyone with PayPal, BTC (or even lightning, can you imagine!), but I want to leave the door open for
34.
by rndhouse 5y ago
I don't claim that this is a free or open source license. The OpenFare license is about monetizing software in the most convenient way possible. I agree with the open source definition as given here: https://opensource.org&#
35.
by rndhouse 5y ago
There are many advantages to defining the payment plan in code. Whether it's defined in the OPENFARE.lock file or the LICENSE file only matters for the sake of simplicity. The LICENSE needs to be the same across many packages so that i
36.
by rndhouse 5y ago
I've been working on a solution along the lines described in the article: OpenFare. With OpenFare, payment plans are defined in code. Which means that the dependency tree can be priced by direct inspection. I've got a working exam
37.
by rndhouse 5y ago
I'm working on a solution where the "FOSS collective" aspect can be decentralized and represented as a protocol. I think it simplifies a lot of things.
38.
by rndhouse 5y ago
Companies also want maintained software libraries where critical vulnerabilities and bugs will be addressed. Code goes stale. Active maintenance has a price. And micropayments mean the price can be spread over thousands of companies. But I&
39.
by rndhouse 5y ago
I've taken another angle at this problem. Instead of collectives we can just define a protocol. A protocol would mean that developers could retain more control. And it would stop the potential need to vet multiple "FOSS collective
40.
by rndhouse 5y ago
I'm working on developing a solution along the lines outlined in the article. But I think there's a way to decentralize the "FOSS collective". I've been working on OpenFare where payment plans are defined in code. C
41.
by rndhouse 5y ago
I'm working on a solution that is along the lines of the "package.lock" method that you've mentioned. My solution involves defining payment plans in code: https://github.com/openfare/openfare#payment
42.
by rndhouse 5y ago
Thanks for the luck! The up-and-coming generation of developers have grown up exposed to millionaire content creators. They might start wondering about their cut.
43.
by rndhouse 5y ago
Most of the value is in the maintenance. In responsiveness to changing demand. I bet all the valuable FOSS software you can think of today is maintained.
44.
by rndhouse 5y ago
There is another way. Where we can have: * modifiable and fork-able code * free for non-commercial use * and payment plans defined in code for commercial use. I'm working on it at github.com/openfare
45.
by rndhouse 5y ago
Creators and artists are making money hand over fist all over the internet. From educational courses to music loops. And copyright plays a big part. But the humble software library developer is on another planet. For them its sponsorship or
46.
by rndhouse 5y ago
I'm working on precisely this problem. My current idea involves payment plans defined in code. See: github.com/openfare/openfare
47.
by rndhouse 5y ago
I'm working on a new way to fund source-available software: OpenFare. The idea is to keep as close as possible to the MIT License with the exception that payment plans defined in code kick in for commercial users. The intention is to b
48.
Funding the Next Million Public Software Contributors(hackernoon.com)
1 points by rndhouse 5y ago|0 comments
49.
by rndhouse 5y ago
I'm working on a solution quite similar to the one you've outlined. OpenFare implements payment plans in code. That means simple setups and programmatic management of payment obligations across software dependencies. If you'r
50.
Funding the next million open source contributors(medium.com)
2 points by rndhouse 5y ago|0 comments
51.
by rndhouse 5y ago
Each developer may choose to minimize the software dependency attack surface to a different degree. Perhaps they would trust a package published by Google without a review. But would require a review before using a package from an indie dev
52.
by rndhouse 5y ago
Hello megumax! I'm working on a solution along the lines that you've suggested: https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be
53.
by rndhouse 5y ago
Each dependency of a software package would have its own separate set of reviews. Anyone can produce a review using Vouch. Official reviews will also be published in the future.
54.
by rndhouse 5y ago
That's right! The purpose of Vouch is to continually decrease the cost of the review process with each new review.
55.
by rndhouse 5y ago
Reviews in Vouch refer to a particular version of a software package. If a new release is issued by a malicious actor, the new release would require a new review. But the review process does not need to re-start from scratch. Reviews from o
56.
by rndhouse 5y ago
A review corresponds to a particular version number. But the review process does not need to start from scratch with each version number increment. Reviews from previous versions can be leveraged to lessen the workload.
57.
by rndhouse 5y ago
That extra code will stand out as not having been reviewed.
58.
by rndhouse 5y ago
I've created Vouch in an attempt to address this problem: https://github.com/vouch-dev/vouch Vouch lets users create and share reviews for NPM packages. Project dependencies can then be checked against those revie
59.
by rndhouse 5y ago
It's completely disingenuous to discuss this topic without taking into account the lightning network.