Open Thread, Aug. 1 - Aug 7. 2016

Elo

If it's worth saying, but not worth its own post, then it goes here.

Notes for future OT posters:

1. Please add the 'open_thread' tag.

2. Check if there is an active Open Thread before posting a new one. (Immediately before; refresh the list-of-threads page before posting.)

3. Open Threads should start on Monday, and end on Sunday.

4. Unflag the two options "Notify me of new top level comments on this article" and "Make this post available under..." before submitting.

If it's worth saying, but not worth its own post, then it goes here.

Notes for future OT posters:

1. Please add the 'open_thread' tag.

2. Check if there is an active Open Thread before posting a new one. (Immediately before; refresh the list-of-threads page before posting.)

3. Open Threads should start on Monday, and end on Sunday.

4. Unflag the two options "Notify me of new top level comments on this article" and "Make this post available under..." before submitting.

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.

0moridinamael10y

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.