[ldubost]

Based on a long experience making open source for a living (I created XWiki, an open source wiki), I think it's though to finance OSS using time based support, at least using usual consulting rate. Either it needs to be understood by clients that the rates should be very high, or have different rates for time based paid contributions versus consulting. Maybe some option could be also to allow paid support by non committers provided they share revenue with the maintainer. If the project is sufficiently popular this could finance maintainers. The maintainer could still provide consulting but at a higher rate. There could also be a special rate for "faster" support, or even a retainer.

Ideally to help sustainability, creators need some fixed yearly support, but while this works for products, it's difficult for libraries.

What is sure is that it's important to bring some margin to the maintainer so he can fund his work.

[tom-lth]

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!

[ldubost]

You are right that there is a difference between products and libs and it seems difficult to get donations or yearly support for libs. Good that it's meant to be another option. I'd like to say that service has helped me get XWiki off the ground, for a product too, but that while you do it you need to have in mind "how to I make the product sustainable with recurrent revenue".

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...

[tom-lth]

Completely agree.

Indeed, I think my ideal target for the first beta users would probably be either small frameworks, or medium size plugins, etc. Frameworks are ideal because they normally have a large amount of contributors (so a lot of potential "helpers") and a lot of people that need support. They also may not have as much documentation as more mature frameworks and therefore possible more people that need help. Of course the end goal would be to work for all types of projects but instead of trying to build the "kitchen sink, I definitely want to concentrate on certain types of users first and get some feedback before moving on further.

As for donations, yes I was thinking the same. I was working on subscriptions (recurring donations) and one-time donations but I shelved this for now until I get some more testing done. I firmly believe (and feedback so far supports this) that people would prefer to use one platform and have one setup for things like that. Doesn't mean they HAVE to, but for people first setting up revenue generating tools, this could be a good plus for them. I also agree, I think a "tip" function could be a great idea and pretty easy to implement.

RE: funds - I shall have to look into this as another feature also, as I can definitely see the usefulness in this but requires some thought of how to implement, great idea!

Thanks again for your detailed feedback, it's much appreciated and hard to come by. It sounds like your project is doing very well, I'm very happy to hear! Massive congrats on building such a huge, useful and widely used software!

I just watched your video / presentation, very insightful and sounds like we're very much aligned in terms of ethos / reasons for getting into things. As for having worked with investors, I couldn't agree more about losing control and having misaligned goals, I am trying to avoid this, for now at least for those very reasons.