Lumifer comments on Open Thread, Aug. 1 - Aug 7. 2016 - Less Wrong

4 Post author: Elo 01 August 2016 12:12AM

You are viewing a comment permalink. View the original post to see all comments and the full post content.

Article Navigation

Comments (81)
Tags: open_thread

Comments (81)

You are viewing a single comment's thread. Show more comments above.

Comment author: Lumifer 01 August 2016 03:47:54PM 5 points [-]

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).

Comment author: gjm 02 August 2016 10:54:12AM -1 points [-]

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 :-).
Comment author: Lumifer 02 August 2016 05:10:21PM 1 point [-]

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.

Comment author: moridinamael 02 August 2016 02:40:00PM 0 points [-]

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.

Powered by Reddit Powered by Reddit