Disclaimers: This system is still a work in process. I look forward to reading (and incorporating!) your (constructive!) feedback and I hope to evo...
For further actions, you may consider blocking this person and/or reporting abuse
A fundamental flaw in the thinking of trying to get an open source project funded/monetized is assuming the people who use it can make the decision to give money (in a subscription model).
Patreon and the likes do not work for companies.
They people who decide to use a certain open source project at work do not have the decision power to make monetairy donations.
I do not really have the solution for this problem.
Maybe the concept of Tidelift is a good one.
Gone are the times where businessed could simply donate resources like servers, as there are plenty of companies offering this for free for open source projects.
I've expensed plenty of software and subscriptions at work before! Things like Dash and irccloud have been critical to my work, and I've found that going through expense processes is definitely possible.
But I know it's not possible for everyone, and that's why I wrote the section on additional licensing, so that more corporate-friendly licensing models can be used as necessary. The patronage model is meant to be a baseline, not a complete story.
I thought that was kinda the point made in this post. That you should offer a commercial license so that it matches the way businesses already expense things.
My employer already pays for various software licenses (including libraries like GSAP), so this kind of license would fit the current model. Meanwhile there's no way I could expense Patreon.
Long-term, do you plan on paying out to small-time contributors, with something like feature/bug bounties? Or the same as with npm, just a strong recommendation to not spend too much time if you're not paid by a third party.
This is a great question, and I really should've written more about it (maybe I'll add it in as an update).
In summary, I think this is a great reason to use OpenCollective, because it makes it easy to do these payouts. I think I'm fairly comfortable taking in small individual contributions that are freely given, but if someone's putting a big patch together, I think the expectation should be that some of the sponsorship money should go to them.
Does that make sense?
I think that's fair. I'm just feeling that there's a lot happening at the maintainers discretion -- but I guess A) you can't avoid that and B) ideally, most of the income is profits, so there are no expectations on how it should be managed (as opposed to with donations).
Correct me if I'm wrong. Scenario: A business discovers their proprietary licensed product uses your Parity licensed product by 2 levels of indirection. (They use an MIT lib that uses an Apache lib that uses your Parity lib). So far as I know, their choices are to either pay you for a commercial license or to replace your lib in their product within 30 days, which could be intractable.
An otherwise permissibly-licensed (e.g. MIT or Apache) project would be bringing a lot of hidden risk/liability to their users by creating a dependency on a Parity-licensed lib. It seems like the only way to make that risk transparent is for the project to change their license to Parity. If projects don't do this, then it will start requiring extra risk assessment to use "permissible" license libs. I remember in the early days of open source that businesses were afraid to use anything with the "open source" label due to risk/liability. I even had to get special lawyer approval for an MIT lib once. I'd hate to go back there.
Another thing that always bothered me about the business model of using AGPL (and I guess Parity) is that the project still isn't really an open source community project. Ownership rights are exercised to do a private commercial release. But if you disappear without sharing or transferring those rights, no one else can ever do a commercial release and those customers are stuck (depending on their commercial license terms). Others can fork it, but they can't choose to release it under a different license. Whereas something like MIT doesn't have this problem since it doesn't cut off any practical usage rights if the author goes off the grid. (Although MIT doesn't solve the "free labor" problem that popular open source projects can have.) Anyway, it's a contingency to think about.
Same disclaimer: I am not a lawyer.
Scenario A (surprise library): this is partly why I explicitly said I'm only recommending this model for devtools, not libraries.
Scenario B (developer going away): shrug. I don't see this as a big issue. Products disappear all the time, people adapt. Look at Google shutting down major projects apparently on a whim.
Dev tools are often packaged up or depended on by other dev tools. Not to mention things like starter templates. Or maybe my definition of dev tools is too broad. Were you thinking like endpoint apps like VS Code or vim? (Although VS Code has been adapted for other uses too.)
I suppose it’s true that products disappear. We’ve had that happen to us or seen it happen to others with some vendors. Because they weren’t making enough money. Anyway, I guess in my mental model, if I decided I was tired of an OSS project I can just stop and someone else can keep it going if it’s important to them. But this is different. It is really a business model, not a community project.
I think if you're concerned about that first scenario, it's important to understand where your tool stands in the ecosystem. I also think it's perfectly acceptable that all those users will, in fact, need to pay for proprietary use. And we can build tools to make that easier.
Very true. I was thinking about that in a twitter thread too twitter.com/tunnckoCore/status/123....
And... now thinking again. This whole problem can be solved with registering a non-profit which will hold the copyright instead of you personally? Of course you still need to have (initially, later the co-maintainers?) few people in that body - family or peers and friends. That way, there would have "official" protocol & rules what and how to happen.
Hm. I may try that way. Thoughts?
In the US anyway, my understanding is that non-profits have ongoing requirements (requires a board, annual meetings, some financial reporting) and are not controlled by a single person -- the board could out-vote you on an issue. So it has non-trivial overhead and some risk as just a vehicle for ownership rights.
I could be wrong on some of the details, but I believe the gist of what I'm saying is true. I have been an observer in formation of one non-profit as well as working for another. Definitely investigate it for yourself.
Ааh, yea, probably. Good to know, I'm looking at UK ones currently.
That's okay. In governance of bigger open source projects it's almost the same thing. There's no problem for smaller ones to be similar too.
My case is that I'm concentrating everything in a single monorepo of independent libraries & devtools and pieces - some connected to each others, others completely not related to other packages.
Anyway, thanks. :)
This is fine if you're starting your own business or freelancing full time... but seems like overkill for an ordinary open source project.
I also feel like maybe you've forgotten what it's like getting started. How Step 7 (quit your day job) sounds laughably impossible, and "getting swept away by the thrill of popularity, the excitement of other people willingly using our code to achieve great things" seems like the best thing to hope for!
Part of the motivation for writing this is precisely because I'm getting started with a new project that can potentially become a major one and I find the current situation unacceptable.
I don't believe it should be, and my intention is to propose a new system that makes this a standard expectation from maintainers of successful projects.
Thanks for taking a stab at it, Kat!
I wrote extensive gulp pipelines and workflows for my organization that have more than 1,100 node modules installed across combinations of packages and their versions. There are many different authors at play. I am not opposed to work towards compensating someone for their efforts if their product provides value at its price, of course, but I am trying to determine how compensation models would work out practically for tools this large, given the amount of authors that would be involved. I suspect that my organization would arrive at having our teams rewrite much from scratch to be proprietary (at a huge cost), pay for turnkey solutions that may not fully deliver, or drastically reduce features to build our applications.
It's quite a conundrum really, and we have seen what happens when altruistic maintainers burn out or move on (recall the event-stream incident). Nobody owes us anything, and we have accepted the fragility that comes with the systems we've adopted.
Based on what I wrote, wouldn't only
gulpitself be Parity, in which case they just pay for a singlegulplicense? Maybe there's a few more packages in there.I think a really interesting bit here is that licensezero itself has tools that automate the process of buying these licenses, and I think that tooling could improve even further if the need arose.
At least gulp but also all its gulp plugins that can be used. I originally thought that I would still need to have awareness of license types for all dependent packages, too, but rereading your post makes it clearer to me that that should be abstracted enough. I wonder where the ultimate responsibility lies if a package has a dependency but does not honor its license or payment model correctly. Is only the package at fault or also my organization for including (and possibly paying) this package while satisfying its but perhaps not its dependent's licenses? That's what made me worry about my large amount of dependencies originally.
As a believer in markets typically finding and providing good solutions, I wholeheartedly agree with you that tooling will improve to satisfy both provider and consumer of these products.
From an ease-of-use perspective, I suspect that one avenue would simply be a subscription model through a registry. You could have registries such as npm compete with other registries similarly to how music and video subscriptions are done. Reducing barriers of entry for consumers is key to choosing services. If an organization was charged X per month or year to have unlimited downloads of packages, that would be a much easier pill to swallow than dealing with individual licensing requirements on a per package or per author basis. With that would come the expectation that service providers a) pay out their package authors / contributors appropriately, and b) some assurances that packages are safe, curated, inspected, etc.
Have you posted about your thoughts and experience with this model since this post? I'm wrestling with sustainability and licensing issues myself for a project that I'm working on and I'm curious where you've ended up.
Edit: Thank you for writing this post in the first place. It was really interesting to read.
Googling got me to this Twitter thread from the author which seems to be dated a year after this post. It seems to have been a frustrating experience which I can completely understand. I still hope to try the Parity license for a project I'm writing but I will go tentatively and will measured expectations.
Thx for putting this together!!!
Regarding the APACHE license in the CONTRIBUTOR.md do you have an example how it should be worded?
A GitHub starter template or example project with everything set up could be great.
Having a template sounds like a great idea! I think I'll work on this soon.
What do you think about NPOSL-3.0 license?
I don't mind people making money using my software, I just don't think they should make that money without giving back in some significant way :)