Open Source, SaaS and Monetization

I have a tremendous amount of and appreciation for Armin Ronacher and many of their fabulous Python libraries which I use regularly. However, this blog post is odd. It says that the open source sass model "has worked out very well for us", but then goes on to say "at one point someone has to make money somewhere.." in order to justify abandoning open source licensing of Sentry.

Maybe "worked out great" means that they got a ton of publicity and traction because they were open source, and now they are ready to abandon open source so they can monetize the traction they gained from being open source in the first place?

Sentry certainly doesn't have any obligation to continue being open source- the old code is still open source- but these events make me question any companies commitment when they claim to be open source. It seems that you can't take any company at their word, even when they publish multiple blog posts about how "committed" they are to open source- because in the end, many companies will do what Sentry did and will dump open source the minute they have gotten what they want from it.

[https://blog.sentry.io/2019/02/14/sentry-thrives-open-source..., https://blog.sentry.io/2016/10/24/building-an-open-source-se..., https://blog.sentry.io/2015/06/30/driven-by-open-source]

And if there was any doubt about Sentry's willingness to use and abuse open source- months after this announcement, they continue to advertise being open source on their site, lying to the community and their customers. https://sentry.io/_/open-source/

Sentry doesn't have any obligation to continue to releasing new code as Open Source, but they should stop lying about being open source.

It is kinda ironic that most people zealously arguing for the "pure" open source definition and harrassing authors here on HN or even on Github issues are the ones who work for FAANG-tier companies and making 6 figures contributing little to nothing to open source projects or getting paid for their contributions. There must be a way to protect authors and small startups from simply being ripped-off by any lazy for-profit entity. I don't think that 99.99999% of users would mind to use an application that is identical with MIT, Apache, GPL plus a clause that protects the author or company that created it.

The author has chosen an approach which makes the software available under the Apache 2.0 license after an embargo period. This is quite okay under the "pure" open source definition (at least for those "liberated" releases, if obviously not in the broadest sense), and nobody is harassing him for that. Many crowdfunding models come with this sort of time-limited "exclusivity".

I had a very similar dilemma myself when putting together a project of mine a few months ago. However, at the end of the day, I felt that keeping the license of the solution (or core solution) as MIT was the best option irrespective, and my thoughts came from the following areas in which monetisation can be substantiated.

- Labor costs for staff, which include developers, network administrators, and support officers.

- Costs incurred for resources, server infrastructure, office resources and so fourth.

- And of course marketing and sales of the solution.

The key is to communicate this substation, therefore asking customers for donations, i feel, becomes irrelevant if you can do that effectively. So really the gist is "it's great that the software is free but someone has to run it and even more so someone has to keep supporting it".

Ideally, my opinion on monetisating comes from the business model which encapsulates the solution, therefore licensing the end product can just be focused around the tangibles that inherently make up the business side of a SaaS company.

I think the most murky part of this dilemma comes from professional services and enterprise grade solutions because this is where custom and closed treatment maybe needed for the client. Plus other issues come more from a security standpoint and trade secret standpoint than anywhere else. For instance customisation on top of a SaaS platform via APIs or integration work may require the asset (or code) to be closed source from the perspective to satisfy the clients' needs, but this has always been an issue and is not a SaaS centric problem as the argument only comes during the purchase cycle of a company and the IT manager asks the question "can our business trust open source?".

The model we are planning to use for the products at Plyint(https://plyint.com) is basically the "Free Software Product" model in a SaaS format. How this will work is we will release the code with a proprietary license, but then if you want to use it in a product or pure open source fork, then you need to go to the trouble of removing the company name and product references. Once, that is done then the license will become an AGPL license that can be used as one would normally expect and any modifications to that code would need to be released again publicly. (This way any fork is required to contribute their code back to the public domain)

I think this will introduce enough time delay that the SaaS service will establish itself. Plus, the product has to become popular enough for anyone to want to go through that level of effort. Also, any significant fork's code will be open source and we can reincorporate that into the original SaaS service as well.