TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Open Source, SaaS and Monetization

118 点作者 ____Sash---701_超过 5 年前

13 条评论

danenania超过 5 年前
I don&#x27;t believe we&#x27;ve been served well by defining the term &quot;Open Source&quot; to also necessarily mean &quot;Free&quot;. This definition and the accompanying zealotry mainly serves big tech and the cloud providers. Everyone else would be better off if we as an industry also make room for software that is Open (in the sense that the code is freely available), but not Free (you must pay or obtain permission to run it yourself, re-distribute it, or run it for others).<p>Open is almost universally good. Open means self-hosting, auditability, ability to patch&#x2F;submit patches for problems yourself, and not being up shit creek if the provider folds.<p>But Free? Free might not <i>always</i> be bad, but it has a lot of problems. Free = a race to the bottom. Free = ads. Free = selling user data. Free = no one cares enough to maintain it. Free = no one cares enough to promote it. Free = no one can afford to hire a UX designer. Free = ripped off by AWS. Free = bait and switch when the VC gets impatient.<p>For all these reasons, you should demand access to the code, yes, but you should also be willing to <i>pay</i> the people who write the crucial software you rely on. It&#x27;s far more sustainable and healthier for our industry.
评论 #22003869 未加载
评论 #22005138 未加载
评论 #22004625 未加载
评论 #22004655 未加载
danShumway超过 5 年前
&gt; Open Source is pretty clear cut: it does not discriminate. If you get the source, you can do with it what you want (within the terms of the license) and no matter who you are (within the terms of the license). However as Open Source is defined — and also how I see it — Open Source comes with no strings attached. The moment we restrict what you can do with it — like not compete — it becomes something else.<p>I appreciate this distinction. I don&#x27;t have anything against a company updating its licenses to remain profitable, as long as they&#x27;re up-front about what they&#x27;re doing.<p>My only complaint about licenses of this nature has been when businesses try to use them to argue that they&#x27;re still Open Source in spirit, or that the restrictions are just technicalities that everyone should ignore, or that Open Source is doomed and they&#x27;re here to save everyone.<p>Not everything needs to be Open Source, but Open Source should mean something.
评论 #22002261 未加载
评论 #22005545 未加载
karterk超过 5 年前
This is a topic that I have been thinking a lot on recently. I&#x27;ve been working on a typo-tolerant instant search engine for a couple of years now called Typesense (<a href="https:&#x2F;&#x2F;github.com&#x2F;typesense&#x2F;typesense" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;typesense&#x2F;typesense</a>).<p>It has not been wildly popular (mostly because I&#x27;ve not really started marketing it) but it&#x27;s loved by those who use it.<p>While exploring how to support its development, there were only 2 options: either to offer a hosted version or premium features which will take some features away from the open source version (essentially open core).<p>A hosted version is essentially ruled out since it&#x27;s a lot of work and will eventually be bettered by AWS :) Open core will mean crippling the main product in some ways.<p>Tricky choice. Eventually I ended up with a middle-ground. Offer a premium version but price it so reasonable (in my case 500 USD &#x2F; year) that it becomes a no-brainer decision. The only downside to this approach is of course you can&#x27;t probably run a company off it but it certainly can support 2-3 people comfortably IF it succeeds.
seanwilson超过 5 年前
I work on a paid Chrome extension that tests if your website follows SEO, speed and security best practices:<p><a href="https:&#x2F;&#x2F;www.checkbot.io&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.checkbot.io&#x2F;</a><p>I considered making it open source but couldn&#x27;t see a way I could monetise it if I tried to charge for it mainly because someone could just upload a free version to the Chrome Web Store. Open sourcing a project also opens you up to taking on a lot more responsibilities as well (e.g. reviewing pull requests, on-boarding new developers, maintaining code standards) and you risk losing control of your own project if you&#x27;re not careful. Helping users with support requests is already enough work when you&#x27;re a solo developer too.<p>Generally, I guess you have to weigh up:<p>1) time investment from open sourcing and maintaining a community vs<p>2) benefits you&#x27;ll get from having open source contributors vs<p>3) increased competition from the open source version<p>With some app ideas, it&#x27;s very hard to reduce the impact of factor 3 which is a shame.
评论 #22004925 未加载
评论 #22004170 未加载
ensignavenger超过 5 年前
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 &quot;has worked out very well for us&quot;, but then goes on to say &quot;at one point someone has to make money somewhere..&quot; in order to justify abandoning open source licensing of Sentry.<p>Maybe &quot;worked out great&quot; 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?<p>Sentry certainly doesn&#x27;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&#x27;t take any company at their word, even when they publish multiple blog posts about how &quot;committed&quot; 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.<p>[<a href="https:&#x2F;&#x2F;blog.sentry.io&#x2F;2019&#x2F;02&#x2F;14&#x2F;sentry-thrives-open-source-software-company" rel="nofollow">https:&#x2F;&#x2F;blog.sentry.io&#x2F;2019&#x2F;02&#x2F;14&#x2F;sentry-thrives-open-source...</a>, <a href="https:&#x2F;&#x2F;blog.sentry.io&#x2F;2016&#x2F;10&#x2F;24&#x2F;building-an-open-source-service" rel="nofollow">https:&#x2F;&#x2F;blog.sentry.io&#x2F;2016&#x2F;10&#x2F;24&#x2F;building-an-open-source-se...</a>, <a href="https:&#x2F;&#x2F;blog.sentry.io&#x2F;2015&#x2F;06&#x2F;30&#x2F;driven-by-open-source" rel="nofollow">https:&#x2F;&#x2F;blog.sentry.io&#x2F;2015&#x2F;06&#x2F;30&#x2F;driven-by-open-source</a>]<p>And if there was any doubt about Sentry&#x27;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. <a href="https:&#x2F;&#x2F;sentry.io&#x2F;_&#x2F;open-source&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sentry.io&#x2F;_&#x2F;open-source&#x2F;</a><p>Sentry doesn&#x27;t have any obligation to continue to releasing new code as Open Source, but they should stop lying about being open source.
评论 #22002953 未加载
jamesbiv超过 5 年前
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.<p>- Labor costs for staff, which include developers, network administrators, and support officers.<p>- Costs incurred for resources, server infrastructure, office resources and so fourth.<p>- And of course marketing and sales of the solution.<p>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 &quot;it&#x27;s great that the software is free but someone has to run it and even more so someone has to keep supporting it&quot;.<p>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.<p>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&#x27; 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 &quot;can our business trust open source?&quot;.
ahnick超过 5 年前
The model we are planning to use for the products at Plyint(<a href="https:&#x2F;&#x2F;plyint.com" rel="nofollow">https:&#x2F;&#x2F;plyint.com</a>) is basically the &quot;Free Software Product&quot; 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)<p>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&#x27;s code will be open source and we can reincorporate that into the original SaaS service as well.
评论 #22002469 未加载
nicpottier超过 5 年前
We are in a similar position and probably survive mostly through luck despite having vendors that sell our Open Source SaaS without contributing anything meaningful back.<p>In our particular case I don&#x27;t think the BSL would work for us, but I definitely understand and support Sentry going this route. FWIW, we have been using Sentry for almost a decade and while we started off hosting our own server we quickly saw the advantage in paying for it instead (and we were happy to do so).<p>It&#x27;s a tough thing to balance for sure, they have been one of the players we watch to see how Open Source SaaS can work and I wish them luck.
soumyadeb超过 5 年前
We have been thinking about this a lot for our open-source Segment project (<a href="https:&#x2F;&#x2F;github.com&#x2F;rudderlabs&#x2F;rudder-server&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rudderlabs&#x2F;rudder-server&#x2F;</a>). We launched things under mongo-SSPL (which is not a OSS approved license) but we now think AGPL is probably good enough for a product like ours. AGPL should kick in for anything (e.g. mobile app) that sends events to the our AGPL-backend so needs to be open-sourced too - that should be a strong enough deterrent for anyone to offer this as a service. Is this statement true? If yes, why did Mongo with with SSPL instead of AGPL?<p>At the same time, we still want businesses who don&#x27;t care about OSS to use Rudder without having to open-source their code. To address that we are thinking of releasing our binary (and AMI images etc) under MIT license. Sure, someone can spin up a SaaS service on the binary but that&#x27;s hard.<p>Any feedback on this would be highly appreciated.
评论 #22003925 未加载
flurdy超过 5 年前
CockroachDB also changed to BSL[1] last summer.<p>I think it is what a lot of my projects would aim to be. Free to use, tweak, contribute. Free to launch products using it. But not free to launch a service as SAAS or API that does more or less the same?<p>* [1] <a href="https:&#x2F;&#x2F;www.cockroachlabs.com&#x2F;blog&#x2F;oss-relicensing-cockroachdb&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cockroachlabs.com&#x2F;blog&#x2F;oss-relicensing-cockroach...</a>
quaffapint超过 5 年前
For my upcoming saas I wanted to do something similar...<p>-Paid hosted saas solution<p>-Freely downloadable to use and install for your own projects<p>...I want people to be allowed to make money with it even if they freely download it, but I just don&#x27;t want them to be able to compete with my hosted saas.<p>I&#x27;m not quite sure that this is what the BSL is saying, so is there a license for something like that?
评论 #22003506 未加载
评论 #22003395 未加载
评论 #22002975 未加载
nif2ee超过 5 年前
It is kinda ironic that most people zealously arguing for the &quot;pure&quot; 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&#x27;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.
评论 #22002242 未加载
nif2ee超过 5 年前
&gt;I remember too many cases of people that tried to do dual licensing with code and ended up regretting it after ownership was transferred or they had a fall out with other partners.<p>Can somebody here elaborate on this?