Open ianlandsman opened 9 years ago
Sounds like a couple of very useful community resources there.
My concern is that these models all involve earning money for doing something that isn't mainstream project development. If your revenue stream isn't directly aligned with your engineering goal, there is always an economic incentive to focus efforts away from the project itself. For example if you make money selling training, the incentive is to write/present more training materials, not develop new features. Yes, new features will require training materials, but only as a side effect. If Taylor was faced with a cash crunch for some reason, or something went wrong with his SaaS platform, you can bet all Laravel development would halt immediately until those problems were resolved.
Of course, this doesn't detract from the fact that people have been able to make a living doing valuable work around an open source community, and it doesn't eliminate the fact that in any non-trivial community, someone has to take on the task of writing the documentation, delivering the training, and packaging the code to make it easier to use. There's definitely a business to be made doing all those things - it just doesn't solve the core problem of paying for mainstream development.
Doing the training is hard. I run godjango.com which does training videos for django and python. However, it doesn't support me anywhere near full time. I know many others that do videos and they too aren't doing it full time. If you are independently doing videos full time you are the exception from my experience. I am excited I am making something so it justifies some of the nights and weekends away from family while allowing me to contribute to the django community, but at this point I don't see it being full time for a few more years. That is a hard slog.
Around the same idea: I used to work for a company who's initial business plan (it changed a lot since) was to: a) build free open-source software b) earn money around selling "partner contract", partners having their bugs and feature request treated as higher priority + some guarantees regarding bug-fixes c) earn money around corporate training (not $10 per video type of fee but more like $1000/head/week) d) donate back 20% of their revenues to other open-source projects they were using
I know of other open-source businesses with the same model. Something similar is obviously happening with Laravel and behind laravel, SensioLab is also doing something similar with Symfony so I think this is not a solution to be dismissed for framework-type products and can benefit the whole eco-system (the donating back 20% of revenue) Now once again, this is not money that's made around getting money from a lot of lambda-users but which is made by targeting a few larger companies
It clearly can work - there's plenty of people doing it. However, as @buddylindsey said, doing training takes lots of time and effort, so the idea that you could do training and open source development seems unlikely. However, if those doing training donate 20% (or whatever) back to the project, then the project itself suddenly gets a viable revenue stream.
The catch is enforcing the 20% donation. Profit-based licensing terms (#14) might be one approach; another would be licensing the Trademark (#20).
@freakboy3742 just so I'm clear, ONE option you'd like to see is a business model where business & financial incentives are tied as closely as possible to actually WORKING on the project (Django, Laravel, Symfony, etc), correct? I'm asking so I'll be clear as I go into this workshop in the morning.
Also, I think the "If Taylor was faced with a cash crunch for some reason" issue is more a matter of implementation than a flaw with the actual model. That's more a matter of "how you operate your business and what goals/metrics you have in place" than "this won't work".
@freakboy3742 I'm writing tutorials for free, they don't get much visibility but are usually well appreciated by the people who read them (ie: I get very few death threats and quite a lot of "thank you's" compared to the size of the audience), I don't do much training anymore though. The Django documentation is great but the tutorial is lacking and as someone has mentioned, some people want more than just documentation, they sometime want as much as step-by-step instructions to do something. And those wanting "more" are usually the ones with means (ie: larger companies)
I want most of my tutorials to stay free (as in beer), but I am not opposed to find a way to partly monetize all of those or fully monetize some others.
So, in the spirit of this thread, would Django or the DSF be willing to accept this kind of contribution (tutorials) to be integrated on the Django website in place of the current tutorial as a potentially revenue generating feature and on a shared income (more like 50% up until a certain amount then fixed fee and the rest goes to the DSF) basis? Those could also be the base for corporate training material.
@kojoidrissa Correct - I'd like to see a business model where an individual could be paid to work on improving open source directly, rather than finding something that generates revenue where developing open source is a side effect, or a reward-to-self if you have spare time at the end of the week.
Regarding cash crunches being an implementation issue: I agree that with discipline, you could probably make a "spend 20% of my time on open source" model work. However, from experience, it requires extraordinary discipline. As an extreme example - if you're faced with the alternative of your business go into bankruptcy, or maintaining your 20% principles... which one is going to win? Plus, IMHO, if you've put yourself in a position where you need discipline, it's because you haven't aligned your incentives with your goals.
I would also argue (and have done, in other tickets), that we don't just need "20% time" - we need 100% time. Maintaining Django is easily a full time job - @timgraham has demonstrated this. And there are some jobs that need full time attention, not just "attention when you can spare it".
@nanuxbe I'm guessing you were joking with the "death threat" comment... but just in case you weren't - if you are getting any death threats, please let the authorities know, and if it's in any way Django/Python related, let the DSF/PSF know so we can do something if we can.
@freakboy3742 I was semi-joking, I didn't receive any death-threats but I know some people in the open-source world do get them.
Also, to go further on the 20% idea and recycling #23. @pydanny & @audreyr (pinging you because you wrote and self-published a very well made Django book) would you be willing to let the DSF sell your book on the Django website and have 20% of that revenue go to the DSF. When I say 20% of that revenue, I don't mean on your own profit margin, but having the book sell for 20% more on the Django website while clearly explaining how that extra cost will be used. I think a lot of people might be willing to spend the extra 20% in the same way people accept to pay higher prices for fair-trade products.
@nanuxbe Have you got any other great ideas you've been sitting on? :-) Assuming @pydanny and @audreyr are up for it, that sounds like a workable idea - a DSF bookshop, vetted for version compatibility et al. It doesn't even need to be a specifically increased price - just sell it as "book price" + "suggested DSF donation" that defaults to 20% (or whatever), in the same way that DjangoCon tickets provide the option at checkout to contribute funds to the travel grant pool.
The only catch I can see is that some publishers already contribute to the DSF as part of their licensing of the Django trademark... but most don't.
Sounds like we've got some sprinting to do on the Django website when we're at DuTH in a few weeks :-)
@freakboy3742 thanks :-)
One of the reason I mentioned 2 scoops of Django is that it is self-published which clears a lot of publisher-related topics like exclusivity clauses or the fact publishers already pay a fee to Django.
Leaving an open donation option might actually bring more money in than just setting a fixed rate.
I think this idea (books + tutorials, seeing businesses like Treehouse leads me to believe there is a lot of money to be done with tutorials) is also a in-win-win concept:
As far as other ideas, on this same topic, if there is a large enough influx of new material, a subscription to the "DSF library" might be a way to bring recurring amounts of money instead of "one-shots" which is always nice to have.
As far as sprinting goes, I believe there will be people from Django CMS there, they maybe have an almost-ready solution for online bookshops?
Has anyone considered the idea of minimum guaranteed income (basic income) as something that could enable more people to be able to work on open-source full time, at their own pace? I have some hope there.
@shurcooL It's mentioned in the blog post by @coderanger on the landing page for the project; it hasn't been raised as a separate idea. My take - it's a nice idea, but if you think #2 will be a hard political sell, basic income will be much harder.
@freakboy3742 I don't really see attaching strings to the use (direct, indirect, commercial, etc) of an open source project working. At least not for most projects. As soon as you have the strings you kill the young community, and without creating a large community none of the other revenue streams are possible at all.
In the Laravel community we've seen a number of business initiatives work pretty well.
Taylor Otwell has launched a few fairly low touch SaaS apps around the Laravel ecosystem which allow him to work full time on Laravel without spending all his time on the businesses.
Jeffrey Way has his training site, https://laracasts.com which is an invaluable community resources and makes enough to allow him to do it full time and give back in multiple ways to Laravel.
At UserScape we run https://larajobs.com which lets us sponsor conferences, contribute financially to many of the Laravel community sites via 50/50 revenue sharing on job listings.
Eric Barnes runs https://laravel-news.com a community news site that is supported via sponsorship and membership.
None of these businesses are going to be fortune 500 companies, but all make enough money to allow direct or indirect support of Laravel and the surrounding community.
Training, jobs, community news, software that supports directly or indirectly the main OSS product are all ways to help financially support OSS.