beeware/paying-the-piper

How do you create a business that pays for open source development?

tleeuwenburg opened this issue · 4 comments

tleeuwenburg commented

One way to get paid to write open source is to get hired by a company to do that, but it's hard. There aren't a lot of businesses doing it. The real question then is how to create a business model in which it makes commercial sense to invest money into open source development at a large scale?

Most very small businesses will not support a full-time software engineer, be that open or closed source. In general, "software" isn't going to be the product, rather some kind of service is going to be the product. If that's true, then the scale needs to be large before the company will need to fund maintenance on that software in order to support their customers.

If you want software to be the product, you must (like any business) identify who is going to pay for your software, and why? In general, the answer is going to be "big business", because small business will probably prefer to buy some SAAS over the web. The web is changing a lot of software into a service through the web as a delivery model, so you really might be able to go through the service business model.

However, let's persist with thinking about how to sell open source software commercially. License agreements do exist which cover this, as does the freemium model. I can think of one way to make this really work: compliance.

A lot of companies need accredited, compliant, secure software. They need to be running systems which are ISO compliant, or security compliant, or guaranteed to have code review etc. They need systems which integrate into their AD servers and other systems.

I would look at ways to make companies pay for these enterprise features, which open source developers are less likely to need for themselves to evaluate and try out the base product.

freakboy3742 commented

This general idea isn't a new one. However, as I mentioned on the landing page for the project, the difficulty is that the source of funding generally isn't well aligned with the project itself.

If you're able to package your project as SAAS, you have to spend a non-trivial amount of time maintaining the deployed service, not improving the code. There's also an economic disincentive to making it easy to install and deploy the code. Lastly, you have a pager to carry around 24/7; speaking from experience, that takes it's toll after a while.

A compliance program has analogous problems. Yes, it can be a viable way of making money, because people with money like their certificates. However, it takes time to develop a certification program. It takes time to sell a certification program. It takes time to deliver training courses. All of this is entirely viable as a business proposition, but it's activity that isn't aligned with what you want to be doing, which is developing the software itself.

One option would be to license others to provide the "official SAAS" or "official compliance" - that way, you can continue to develop the software, and just take a cut of the profits that others are making. However, this dilutes the profit stream (since you're not going to get 100% of the profits from your accreditation group). It's also not an option that is available to smaller projects - who is going to pay for accreditation for Django Debug Toolbar, for example?

tleeuwenburg commented

So, I agree, BUT...

This is exactly what commercial / close-source businesses do which is what makes them money.

(A) If you want a job working in open source, but don't want a business, then really you just need to find those businesses and apply for jobs.

(B) If you want to change the business landscape, you have to go into business.

If you want (A) but need (B) first, then you need to partner with someone who can do (B) or do it yourself.

The way I see it, there is no solution to (A) that doesn't involve somebody solving the business-side problem, other than the traditional mode put forth in "The Cathedral and the Bazaar", namely contribution to the common good out of enlightened self-interest.

Accepting for the sake of argument that someone needs to solve (B), this post was about my consideration of the business-side problems, to bring a discussion about potential business models out into the open.

ncoghlan commented

This was roughly the topic of my PyGotham and PyCon Poland keynotes earlier this year.

(Since giving the PyCon Poland edition of that talk I've realised the feeling of "I'm trying to cover too much, but I don't know what to cut" is likely due to the fact that I switch back and forth between talking about business models and our interests as individual developers - it would likely be better if it was split into two talks, one tailored for folks setting up an open source business, and one for individual developers wanting to work on open source in the context of a larger organisation)

I'll also highlight this set of articles by John Mark Walker (now Director of Open Source Strategy at EMC):

ncoghlan commented

I also wrote an article for Red Hat's community blog earlier this year on why an organisation might fund their employees spending time working in the open: http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/