I hate sponsorware concept OP is proposing. It seems to work for him but it’s opposite to the spirit of open source. His idea is that keep code secret until you find N sponsors. Further, he will hide important tutorials if you are not sponsor. I would hate to use this kind of open source project.
Here is more viable freelancing:
- create framework/library that everyone needs
- for feature requests/bug fixes, prioritize sponsors
- do office hours for sponsors
- invite sponsors/allow them to vote for future road map
What you're proposing requires him to sell his time instead of his work (which was already a portion of his time). It is impossible to scale that type of consulting work to multiple clients because you'll always be limited by your available time.
The spirit of open source isn't so sacred. In most cases it is hundreds or thousands of businesses benefiting financially from the work you've done.
Implying his approach is not viable is weird, given that what he's doing is demonstrably working (at least at the moment). He's making free software and then selling subscriptions to training content, which is where he seems to be making something like 80% of his revenue. It's like Railscast, Laracast, Egghead.io (originally just angular tutorials!) etc.
The main difference to railscast, egghead.io etc. is that he's using Github as a payment processor & to manage subscriptions.
Well from what I've seen the Sponsorware concept is the ONLY monetization strategy I like from both a developer and a user. What alternative is better?
- Consulting, usually means the project is too complex and hard to use without help. Changes to make the project easier to configure are often not even considered...
- Donations, not sustainable for the developer (no users need to pay anything).
- Open-core, one of the worst strategies, as the developer's motivations are almost completely opposed to the open-source community. The developer wants people to upgrade to premium, so the premium features are always prioritised over community features, and people can't extend the software themselves...
- Hosting, not a bad strategy, but is slowly becoming less relevant as deployment of services is becoming increasingly easy.
That sounds more like straight up working to me. This way he's building features he's interested in and allowing some people to get a sneak peek, if you will.
I'm not sure how sponsorware is the opposite to the spirit of open source but your proposal would essentially allow someone to buy out the product roadmap which seems worse.
You are free to hate and free not to use such a product.
The truth is that many developers have taken the high road, and done the right thing, and they have been unable to make a living out of their open source efforts.
I hate that the ecosystem is so weak the OP has to resort to this model, but I have nothing but sympathy for the OP.
+1, Parent comment comes off as devs owe others anything labeled “open source” but OP is not selling open source — it’s software that’s been paid for, made public.
The whole entitlement that devs and companies have around open source drives me crazy.
Genuine question time: assuming that someone has created the "framework/library that everyone needs"[1], at what price points should that person be setting their sponsorship tiers, along the lines that you suggest, on GHSponsors? Perhaps something like:
- Thanks/gratitude: $5
- Prioritise issues raised by sponsors: $25
- Sponsor influence/vote on project roadmap: $300
- 1hr/month video-call/consult with sponsor's company/team[2]: $600
- Add sponsor's logo on the project's home page[2] (say for 1 year) - in a fun and engaging way, of course: $1000
[1] - I've done this, except for the bit where I convince everyone that they really, really need to use the library.
[2] - I've not yet seen a way on GHSponsors to limit the number of people who can sponsor a given tier. Which puts me off offering this sort of tier as over-subscription could quickly steal all my time and ruin my project's home page.
Nice idea, but most people want open source for free, and never contribute back, and so we only get code that big companies want, and not individual driven things that often have better ethics behind them, instead of the companies ulterior motive.
While the term open-source is a bit more vague, I'd argue that the software he's developing fits squarely into the term "free" (as in speech), as the FSF defines it. The source code is available to modify and fork, even if you must pay to access it -- which is allowed while still considering it "Free". I've always wondered how the FSF thought that would work exactly, since it seems weird to have something be forkable to only a select group of people, but this makes a lot of sense; it will be open sourced to everyone after enough people pay for it.
I'd also argue that this is one of the most ethical ways to pay developers fairly for their work, even if the author wasn't able to make that much money from it. The product the developer creates is FOSS, available to everyone after some time, and they still get paid for it (bonus; they're paid by the open source community for their work, rather than from one person/corporation that dictates their salary).
Practically it is closed-source and then once financial targets get satisfied (sponsors, sale, maintenance contracts) one open-sources it. Thus is how a lot of enterprise software gets opened.
If it is trully open-source from start then anyone can freely dostribute the copy outside of the elite group.
It doesn't seem to be working great though, at least on the page. I end up making a living through ad-hoc client work, which sometimes supports the open-source side as well.
> - for feature requests/bug fixes, prioritize sponsors
Isn't this equivalent to "keep code secret until someone sponsors you?" Except in his case, the work is done before you're sponsored, and in yours, the work is done after?
His idea has better incentives. He doesn't have to insert himself or make consulting necessary, he has an incentive to make the running costs as low as possible, and the manuals as good as possible. Among other things.
Here is more viable freelancing:
- create framework/library that everyone needs
- for feature requests/bug fixes, prioritize sponsors
- do office hours for sponsors
- invite sponsors/allow them to vote for future road map
- offer consulting credit to sponsors