| Thanks for the response. Much appreciated, and kudos on xwiki, very impressive project!! Agreed, it is difficult. The thought process for this came from my own personal experience of deprecated or poorly documented libs I have used. It was impossible to get any of my superiors to "donate" to help make sure libs we used didn't get deprecated (never a promise of course, but helps). However I know that I would have been able to get $100 here and there to save time as it's a win-win even if I pay for it myself... With regards to the consulting rate and paid support rate, I agree. Although I won't know until I have some decent beta testers (LMK...), it's hard to simulate. My thinking here was that it's just another option and for medium size projects to even get $5 on GitHub sponsors seems difficult (as I have been told). This way if they have an rate of $150/hr and they can solve my issue in 30 mins, they just got $75 they didn't have before. But I know it may not be that simple, I just don't personally think that the bug bounty services that try to solve (part of) this problem do a good job of it and are often waaaay undervalued. With regards to the maintainers, etc. That was also my thoughts. While you're not going to get the main developer for symfony or vuejs, they do have hundreds of contributors. Because the platform only let's you provide support for repos you've actually contributed to (or own), this kind of handles that. The actual "owner" of the repo can set a rev share on their end so they automatically receive $X% from everything for those repos. It kind of gets complicated though because then you could of course end up with a not too skilled one-time contributor providing crappy support, which is why I also implmented controls for the owner to mark who can and cannot provide support. Anyway I appreciate the feedback and just wanted to expand on some of my thinking on your points as I have spent a lot of time mulling them over and I think until I get some real data I will not know how it works in reality, or how it is received / which features are actually useful or liked and which are seen as terrible... >Ideally to help sustainability, creators need some fixed yearly support, but while this works for products, it's difficult for libraries. Completely agree, and while I have spoken to many that can get yearly support, as you said, it's not often libraries and is also quite hard to come by for medium projects. >What is sure is that it's important to bring some margin to the maintainer so he can fund his work. 100%, that is the main purpose of it really. It's so difficult to get anyone to donate or sponsor, so was just trying to come up with a way that I would personally use, which would be good for devs and get some money back in the pockets of the maintainers. Apologies for the lengthy response! |
For libs, I believe what you need to think about is who the lib maintaners are and in what context do they do it ? How many are freelancers ? How many employed ?
One thing that you could do in your service is to allow for links to donations and maybe chip in extra in the service costs even if it's not demanded. I still think that the donation market can expand with open source funds. At XWiki we have a fund (for which we have a hard time completing the work of project sélection). One thing we miss most is knowing which projects really need to donations.
As you say, it's hard to get the superiors to even give a donation. However if you can mask the donation in some "needed service" it can work. At XWiki we created open source extensions which are paying (not packaged for free). I'm not sure for libs it work though.
If you are interested in how we got XWiki off the ground and funded, I had a fosdem talk about it. There are slides and video here: https://fosdem.org/2024/schedule/event/fosdem-2024-1830-20-y...