[HN Gopher] Choosing a Model for Your Open Source Business (2017)
___________________________________________________________________
Choosing a Model for Your Open Source Business (2017)
Author : neinasaservice
Score : 37 points
Date : 2021-01-11 13:05 UTC (8 hours ago)
(HTM) web link (snipe.net)
(TXT) w3m dump (snipe.net)
| a9t9 wrote:
| Nice overview.
|
| "Freemium is a harder model to implement in open source, since
| the source is, well, open, but we do see this in things like
| WordPress...."
|
| => Just to add another flavor: The Freemium model is working well
| for us even so we are _not_ SaaS.
|
| In our case, the main part of the RPA software is open-source
| (GPL) and free. All Internet access is only done within the open-
| source core.
|
| The features of this core app can be extended by local native
| apps for Mac, Linux and Windows. These are proprietary/closed
| source.
| teddyh wrote:
| See also _Selling Exceptions to the GNU GPL_ :
| https://www.gnu.org/philosophy/selling-exceptions.html
| open-source-ux wrote:
| Among the thousands of open source projects, the ones championed
| as successful open source business make up a tiny proportion i.e.
| the _exception_ not the norm.
|
| Meanwhile the SaaS business model continues to eat the software
| market. A model that gives users less control than the desktop
| software model. And where the source code (built on open source)
| is not visible.
|
| Open source software has been critical to the success of the SaaS
| model. You could argue SaaS is the true success of the 'open
| source business model'. Just not in the way open source advocates
| expected it to be.
|
| There is another option - one that some open source advocates
| will immediately dislike: source-only products i.e. you sell your
| software product to customers to run them themselves. You give
| them the source code of your product so they can customise it to
| meet their needs. But the software is not open source and cannot
| be shared the way open source can.
|
| There are successful source-only products. Two examples: Craft
| CMS and Kirby CMS. Both publish their source code on GitHub [1]
| [2] and rely on the honesty of their customers to pay (which they
| do). They have a thriving community of developers making plugins
| and extensions - proving that you can create a community of
| developers around a 'source-only' product.
|
| [1] Craft CMS: https://github.com/craftcms
|
| [2] Kirby: https://github.com/getkirby
| james_impliu wrote:
| > Among the thousands of open source projects, the ones
| championed as successful open source business make up a tiny
| proportion i.e. the exception not the norm.
|
| I think this is a correlation not a causation thing.
| Specifically, open source is a great place to put hobby or WIP
| projects - SaaS isn't, you wouldn't want to pay for others to
| use your stuff for free. Certainly, historically, your point is
| valid - SaaS has benefitted hugely thus far, but I think it
| seems rational this starts to change.
|
| Open core feels like it has the advantage of the source-only
| approach yet also enables a community to use a free product on
| top, generating faster growth and user trust and feedback, all
| of which are harder to create with SAAS. The downside? You have
| to build two products. At least for those willing to do the VC
| route (not for everyone), it is possible to get funding to do
| this.
|
| Disclaimer: I am a co-founder of a VC-backed open core company!
| MayeulC wrote:
| > Among the thousands of open source projects, the ones
| championed as successful open source business make up a tiny
| proportion i.e. the exception not the norm.
|
| I think that open source projects tend to be smaller. However,
| is size the correct proxy for success? I would argue it isn't
| for companies, and rather the opposite in fact.
|
| A small company that does well what it set out to do is
| successful in my view, even if you can count the employees on
| one hand. Likewise for software projects. Also, maintenance
| mode is a thing, and it's all right, so the number of commits
| isn't a good proxy either, IMO.
| orlandohill wrote:
| The Polyform Project has a set of standardized _source-
| available_ licenses. These can be used for a dual-licensing
| business model. Customers can use the software for free under
| the terms of the _source-available_ license, or pay to buy a
| proprietary license.
|
| https://polyformproject.org/
| mrskitch wrote:
| I think dual licensing is possibly the best way to go, if your
| product mitigates a risk. It's why we went that way with
| browserless.io
|
| Truth be told selling a small library probably isn't enough to
| make significant money on your product since it isn't solving a
| big enough risk. The risk of forking is fairly low, especially
| for small to mid sized companies. Larger companies, maybe so
| since things like security become much more urgent.
|
| It's hard to separate people from their money, but I feel it
| becomes a lot easier if it offsets a potential risk they're not
| willing to take. Just my 2 cents.
| ralmidani wrote:
| I used to be a Copyleft zealot. But eventually I realized that an
| absolutist insistence on "Free as in Freedom" has become
| outdated: when the GNU project was started, it was not easy to
| distribute copies of large programs. That is no longer the case
| (you can now serve complete photo editors, IDEs, etc. over the
| web). The FSF thinks it's OK to "sell" your program, but if it's
| under a "true" FOSS license, how do you get compensated for the
| value your program provides to those who get their copies from
| the person/company who initially paid you? And what's to prevent
| a group of people/companies from pooling their money and
| pretending there's only one customer willing to pay for your
| product?
|
| Zealotry makes it impossible to have a middle ground between
| "Four Freedoms" and "all rights reserved", and insisting there's
| only one true way to do FOSS will lead to 100% proprietary
| software dominating end-users (which is who the Four Freedoms
| were about in the first place).
|
| I think an approach that preserves some of the Four Freedoms,
| while restricting distribution of the core program, would still
| be in agreement with the spirit of FOSS. For example, what's
| wrong with a license that lets anyone study the program, modify
| it, etc. but empowers the Copyright owner to collect money from
| those who run it in production? If selling your program is OK,
| but modern technology makes it impossible to be compensated
| fairly by users of your software (and even worse, competitors
| with deep pockets can out-scale you and put you out of business),
| this seems like a reasonable middle ground.
| orlandohill wrote:
| Putting certain restrictions on The Four Freedoms for the sake
| of building a sustainable business sounds very reasonable.
|
| Some licenses put restrictions on freedom 0, the right to run
| the program. That's the approach taken by Prosperity and the
| Polyform licenses.
|
| https://prosperitylicense.com/
|
| https://polyformproject.org/licenses/
|
| The Parity Public License takes a different approach, and
| expands the concept of copy-left to require developers to
| release the source code for all of the software that they
| develop with the program, not just software that they
| distribute to others.
|
| https://paritylicense.com/
___________________________________________________________________
(page generated 2021-01-11 22:02 UTC)