I’ve made an app that would greatly benefit from being open source in order to allow users to write their own plugins. How do I make it open source while still satisfying my capitalist rent-seeking exploitative desires?
If the code is available in a form that enables people to build it, that seems likely to reduce sales considerably whatever the licence. (In any case, I don’t think CC-ness of the licence is the relevant feature.)
If the source code is available then nagging, begging and crippling are easily removed. (Unless the crippling is a matter of omission and the uncrippling bits are paid for—but that’s just one variety of freemium.)
Your first suggestion, a good plugin API, seems like the way to go. moridinamael, what advantages do you see to open source over a plugin API?
Other possible options:
Divide the app into two parts. One is open-source and is the part that would be extended by plugins. One is closed-source and has most of the secret sauce in it. Someone buying the app gets the binaries for both parts and the source for the extensible part. Of course this is only any good if you can find a way to split the app up that doesn’t kill its efficiency or break its architecture.
The open-source extensible part might be minimal (just enough to support plugins—this ends up looking a lot like the “plugin API” option, I think) or maximal (so that the only closed-source part is an “engine” that does some clever thing you are hoping other people can’t duplicate) or in between.
Have part of the app run not on the user’s computer or mobile device but on servers under your control. Charge for access to those servers.
Just make it open source and do something entirely different to satisfy your capitalist rent-seeking exploitative desires :-).
With respect to making the source available, the consequences depend on the target market and the price. For a multi-thousand-dollar product aimed at STEM professionals, yeah, people will bother to recompile without the offending bits. For a mass-market app priced at $0.99 no one will bother.
But I agree that some plugin API looks like the most natural way to proceed.
I agree that creating an API is probably the smartest way to go about it. The “disadvantage” to that approach is that I have to build and maintain an API.
The app architecture as it exists is also somewhat conducive to being “split” into an open and extensible part and a closed engine. However, I might wish I had just gone to the full effort of building an API, so that I don’t have to constantly mentally track what parts of the code can reside in the be public modules.
Having the app run on a server is also possible, but I have no familiarity with doing that.
You could publish it as GPL3 or something more restrictive. If someone else has a plugin that has commercial potential, they’ll need a more permissive license.
You don’t need to publish a software as open source to allow people to write plugins at all.
As far as the definition of open source goes, nobody considers Windows to be open source just because some of Microsofts customers have access to the source code.
I’ve made an app that would greatly benefit from being open source in order to allow users to write their own plugins. How do I make it open source while still satisfying my capitalist rent-seeking exploitative desires?
One way would be to expose an API to plugins but remain closed-source.
Another way would be to open-source the code but not release it under a CC license.
Yet another would be to release the app as {share|nag|beg|cripple|etc}ware.
Yet another would be to make the app free but charge for support and enhancements (freemium).
If the code is available in a form that enables people to build it, that seems likely to reduce sales considerably whatever the licence. (In any case, I don’t think CC-ness of the licence is the relevant feature.)
If the source code is available then nagging, begging and crippling are easily removed. (Unless the crippling is a matter of omission and the uncrippling bits are paid for—but that’s just one variety of freemium.)
Your first suggestion, a good plugin API, seems like the way to go. moridinamael, what advantages do you see to open source over a plugin API?
Other possible options:
Divide the app into two parts. One is open-source and is the part that would be extended by plugins. One is closed-source and has most of the secret sauce in it. Someone buying the app gets the binaries for both parts and the source for the extensible part. Of course this is only any good if you can find a way to split the app up that doesn’t kill its efficiency or break its architecture.
The open-source extensible part might be minimal (just enough to support plugins—this ends up looking a lot like the “plugin API” option, I think) or maximal (so that the only closed-source part is an “engine” that does some clever thing you are hoping other people can’t duplicate) or in between.
Have part of the app run not on the user’s computer or mobile device but on servers under your control. Charge for access to those servers.
Just make it open source and do something entirely different to satisfy your capitalist rent-seeking exploitative desires :-).
With respect to making the source available, the consequences depend on the target market and the price. For a multi-thousand-dollar product aimed at STEM professionals, yeah, people will bother to recompile without the offending bits. For a mass-market app priced at $0.99 no one will bother.
But I agree that some plugin API looks like the most natural way to proceed.
I agree that creating an API is probably the smartest way to go about it. The “disadvantage” to that approach is that I have to build and maintain an API.
The app architecture as it exists is also somewhat conducive to being “split” into an open and extensible part and a closed engine. However, I might wish I had just gone to the full effort of building an API, so that I don’t have to constantly mentally track what parts of the code can reside in the be public modules.
Having the app run on a server is also possible, but I have no familiarity with doing that.
Thanks for your thoughts.
You could publish it as GPL3 or something more restrictive. If someone else has a plugin that has commercial potential, they’ll need a more permissive license.
You don’t need to publish a software as open source to allow people to write plugins at all.
As far as the definition of open source goes, nobody considers Windows to be open source just because some of Microsofts customers have access to the source code.