Why Open Source?(getconvoy.io)
getconvoy.io
Why Open Source?
https://getconvoy.io/blog/why-open-source/
110 comments
I agree with your perspective but let me try to formulate an argument against that.
1. Trust over a product or platform can be formed in many ways. Opensource is an irreversible way of doing that. I have often seen people equate opensource to free usage of the product, it is great for adoption but very bad when it comes to monetization. Even if your project is available as OSS if you don't have community around it, disappearance of the org is still a threat.
2. If there is no market, you don't any incentive to maintain it forever. Google fusion tables is probably that case. The market perhaps was not large enough.
3. I do buy into incentive to opensource for building an eco-system
4. I do buy into the larger impact argument but question is - will you keep maintaining it if there is no incentive for you in the process?
I have seen lately, lot of VC backed orgs posting OSS as a differentiating factor than their competitors. I am not sure if I would buy into that argument.
1. Trust over a product or platform can be formed in many ways. Opensource is an irreversible way of doing that. I have often seen people equate opensource to free usage of the product, it is great for adoption but very bad when it comes to monetization. Even if your project is available as OSS if you don't have community around it, disappearance of the org is still a threat.
2. If there is no market, you don't any incentive to maintain it forever. Google fusion tables is probably that case. The market perhaps was not large enough.
3. I do buy into incentive to opensource for building an eco-system
4. I do buy into the larger impact argument but question is - will you keep maintaining it if there is no incentive for you in the process?
I have seen lately, lot of VC backed orgs posting OSS as a differentiating factor than their competitors. I am not sure if I would buy into that argument.
> will you keep maintaining it if there is no incentive for you in the process?
Speaking personally, Datasette is the first project I've worked on in my entire career where I'm confident that I would be delighted if I was still working on it in 10-15 years time.
The space it operates in - analyzing, exploring and publishing data about the world we live in - has completely limitless appeal to me. Every project I've ever cared about can be attached to it, especially given the plugin architecture which supports me trying out all kinds of weird and interesting applications for the core technology.
If I can't make it work financially it can go back to being a side-project for me. I'm confident the financial side of it can work though.
Speaking personally, Datasette is the first project I've worked on in my entire career where I'm confident that I would be delighted if I was still working on it in 10-15 years time.
The space it operates in - analyzing, exploring and publishing data about the world we live in - has completely limitless appeal to me. Every project I've ever cared about can be attached to it, especially given the plugin architecture which supports me trying out all kinds of weird and interesting applications for the core technology.
If I can't make it work financially it can go back to being a side-project for me. I'm confident the financial side of it can work though.
> Speaking personally, Datasette is the first project I've worked on in my entire career where I'm confident that I would be delighted if I was still working on it in 10-15 years time.
I feel the same way about cloud custodian and starting stacklet, but I also put stuff into a foundation, so that it has proper survivability beyond the org, irrespective of the org's decisions (Ala hashicorp), and true survivability and impact on an oss project means getting past individual contributor bus factor.
I feel the same way about cloud custodian and starting stacklet, but I also put stuff into a foundation, so that it has proper survivability beyond the org, irrespective of the org's decisions (Ala hashicorp), and true survivability and impact on an oss project means getting past individual contributor bus factor.
I wish you success. I think you are super motivated and vision is very clear.
> Speaking personally, Datasette is the first project I've worked on in my entire career where I'm confident that I would be delighted if I was still working on it in 10-15 years time.
That's a bus factor of 1?
You know what's more cool though? A 100 years: https://archive.is/qnWWX (didn't work out all that well for Evernote, regardless). I'm sorry but this script has been sequel'd over again and again. May be, just may be, you're a unicorn (:
That's a bus factor of 1?
You know what's more cool though? A 100 years: https://archive.is/qnWWX (didn't work out all that well for Evernote, regardless). I'm sorry but this script has been sequel'd over again and again. May be, just may be, you're a unicorn (:
Part of the reason I want to make the project financially sustainable (aka earn enough to hire a team) is to increase that bus factor.
I've been using and pitching datasette at my employer for a long time now. It's just so useful for so many ad-hoc tasks in my work.
With all due respect, a project being open source means nothing for trust. There's a litany of open source projects that I have used that have been completely abandoned.
Trust comes from building a healthy ecosystem of users, which ultimately comes from building a good product.
Trust comes from building a healthy ecosystem of users, which ultimately comes from building a good product.
>Trust comes from building a healthy ecosystem of users
Trust comes from the publisher/author being truthful and honest with users, nothing else. By publishing source code, an open source software publisher is making a strong statement towards trust: you can see everything. Nothing is hidden (this is not true though when a company uses an open source client and closed source back end strategy).
> There's a litany of open source projects that I have used that have been completely abandoned.
There's also a litany of abandoned closed source commercial software and SaaS products. Keeping commercial software alive requires money. Keeping open source alive requires time. In the end, both are scarce and the author/publisher has to make a decision on what to invest in, and sometimes the software they sold to me last year doesn't get that investment. If it did, I'd still be using NBI Legacy to write documents, I'd be running OS/2, Microsoft Bob would be helping users make Windows work, and I could read news with Google Reader (aside Bob, all of these were at least good products. Bob was... ahead if it's time).
Trust comes from the publisher/author being truthful and honest with users, nothing else. By publishing source code, an open source software publisher is making a strong statement towards trust: you can see everything. Nothing is hidden (this is not true though when a company uses an open source client and closed source back end strategy).
> There's a litany of open source projects that I have used that have been completely abandoned.
There's also a litany of abandoned closed source commercial software and SaaS products. Keeping commercial software alive requires money. Keeping open source alive requires time. In the end, both are scarce and the author/publisher has to make a decision on what to invest in, and sometimes the software they sold to me last year doesn't get that investment. If it did, I'd still be using NBI Legacy to write documents, I'd be running OS/2, Microsoft Bob would be helping users make Windows work, and I could read news with Google Reader (aside Bob, all of these were at least good products. Bob was... ahead if it's time).
Being truthful doesn’t mean much. Actions are worth much more than words.
What trust is seeing how a product has evolved over 5-10 years.
I think you’re missing my point. My point is focusing on whether a project is open source is relatively meaningless. It’s like using the price at a restaurant to judge the quality of food… it’s almost meaningless.
What trust is seeing how a product has evolved over 5-10 years.
I think you’re missing my point. My point is focusing on whether a project is open source is relatively meaningless. It’s like using the price at a restaurant to judge the quality of food… it’s almost meaningless.
Being truthful is an action, the best kind of action. It develops trust with people over time.
It means a lot to me. Thats the first thing I look for in a company/concept. releasing code to the public is an act of social responsibility. I means quite a bit to the public good.
The public good still exists no matter what people in business think. It just takes awhile to effect your bottom line if you ignore it.
The public good still exists no matter what people in business think. It just takes awhile to effect your bottom line if you ignore it.
> There's a litany of open source projects that I have used that have been completely abandoned.
Yes, but being able to continue using, and even fixing bugs in the abandoned project is way, way better than having a useless pile of bits because the license server was taken offline. If may not be a great situation and you may well want to migrate to something else, but it is a far more graceful exit than closed-source software usually is.
> Trust comes from building a healthy ecosystem of users, which ultimately comes from building a good product.
This isn't enough. Great products with many users are often acquired and shut down or just change their licensing strategy to be unsuitable (either too expensive or too restrictive).
Yes, but being able to continue using, and even fixing bugs in the abandoned project is way, way better than having a useless pile of bits because the license server was taken offline. If may not be a great situation and you may well want to migrate to something else, but it is a far more graceful exit than closed-source software usually is.
> Trust comes from building a healthy ecosystem of users, which ultimately comes from building a good product.
This isn't enough. Great products with many users are often acquired and shut down or just change their licensing strategy to be unsuitable (either too expensive or too restrictive).
Did you have the newsroom angle and monetization plan in mind when you started working on Datasette? Or did you start working on it first and then come to the monetization strategy after you realized that it resonated with people?
It's been inspired by newsrooms and data journalism since the start, see https://simonwillison.net/2018/Aug/19/instantly-publish-data... for the story.
I made an open source license that you may be interested in. It's basically the AGPL + copyleft for _services_ that are dependent on your service, as well as build tools. You can check it out here: https://github.com/candiddev/cpl.
That's kind of like saying "I have a fork of bash that you may be interested in". It fails the familiarity test, and that's really important.
Does that really matter in the context of a license though? The terms are the terms, if folks don't agree with the terms they can negotiate different ones or not use it.
There isn't a lot of people thinking, gee, I want an unfamiliar license, so you're going out on a limb by showing someone a new one. Just like if you made a fork of bash with some new feature and were like, "here, use this".
If you want your software to be used, yes it matters very much.
matters a lot, most orgs have a whitelist of permitted licences, and if some software you want to use isn't on it you have to jump through loads and loads of hoops, so much its usually not worth it.
I said almost exactly the same thing a decade ago with my own project.
I learned a lot in that time.
It’s closed source now.
I learned a lot in that time.
It’s closed source now.
How are you going to monetize it? Your site has no mention of pricing.
I'm going to charge organizations a monthly fee for using the hosted SaaS service.
Implementing billing and setting pricing is next on my TODO list!
Implementing billing and setting pricing is next on my TODO list!
Will the billing system itself also be an open source plug-in for datasette? :D
Sadly not, it's going to be a Stripe subscription management dashboard!
So now you have to manage both the core software and the hosted version.
Whereas your competitor just needs to build a hosted version, use the core you provide for free, thereby having a fraction of the expense and the ability to undercut you on price.
You have to realize going in that once you try to monetize your open source, some of your users become your competitors. They’ll tell you how great you are, while cashing checks off your hard work.
Whereas your competitor just needs to build a hosted version, use the core you provide for free, thereby having a fraction of the expense and the ability to undercut you on price.
You have to realize going in that once you try to monetize your open source, some of your users become your competitors. They’ll tell you how great you are, while cashing checks off your hard work.
> Open Source is the ultimate form of sustainability.
If the company that produces open source fails, the software doesn't have maintainers anymore. Unless someone else picks up working on a possibly hugely complex piece of code, you will have an outdated, possibly full-of-secholes relic in no time. Software isn't static.
So many open source projects have a funding problem. A single company pays the 5-15-50 developers it takes to keep it alive, build releases and so on, and then suddenly goes under or pulls funding.
You can't just simply take over the mainenance of a large project at the snap of your fingers. The projects mentioned in the article are the exception, not the rule. The "community" doesn't typically come up with funding to the tune of several million dollars a year, nor does it have the know-how on all the details.
If you need an example, take a look at the commit graph of the oVirt project [1] after Red Hat decided to sunset it. No forks, very little in the eay of new maintainers. Unless you want to risk it, you probably need to move off oVirt sooner or later. (Bias disclaimer: I worked on the Kubernetes/OpenShift integration for oVirt for ~2 years.)
[1] https://github.com/oVirt/ovirt-engine/graphs/commit-activity
If the company that produces open source fails, the software doesn't have maintainers anymore. Unless someone else picks up working on a possibly hugely complex piece of code, you will have an outdated, possibly full-of-secholes relic in no time. Software isn't static.
So many open source projects have a funding problem. A single company pays the 5-15-50 developers it takes to keep it alive, build releases and so on, and then suddenly goes under or pulls funding.
You can't just simply take over the mainenance of a large project at the snap of your fingers. The projects mentioned in the article are the exception, not the rule. The "community" doesn't typically come up with funding to the tune of several million dollars a year, nor does it have the know-how on all the details.
If you need an example, take a look at the commit graph of the oVirt project [1] after Red Hat decided to sunset it. No forks, very little in the eay of new maintainers. Unless you want to risk it, you probably need to move off oVirt sooner or later. (Bias disclaimer: I worked on the Kubernetes/OpenShift integration for oVirt for ~2 years.)
[1] https://github.com/oVirt/ovirt-engine/graphs/commit-activity
For sure, but this is infinity better than some close sourced project (like hardware driver, old iphone), where the user are stuck because the code is NOT open. What you are mentioning seems like a business and funding issue in general for software development. However, in now days and age everything (beside private key) ought to be open sourced. That is how a transparent work will work. And as we can lack of transparency has caused way more problem than problem such as oVirt project
I agree that it would be better to have the source code for things. However, what good is the source code if you don't know how to, or even worse, can't build it because it was always built using an intricate web of build systems that rely on servers that no longer exist? Can I patch and recompile the project on my computer and is it easy to find out how to do it? Do I even have the tools to build it freely available? Unfortunately, a great many open source projects fail this test.
While on the topic, I think EUPL should become the default license for open-source projects in the business context. It's a weak copyleft license (OSI and FSF approved), so it does not strike mortal fear of "viral" license spread on business partners. Similar to EPL, MPL, and LGPL, it creates an obligation of sharing back the changes made to weak-copyleft licensed portion of the code. Finally, EUPL closes the SaaS loophole, which is similar to a non-existent Affero LGPL license.
The EUPL has a lot of things going for it: it's readable by mortals (unlike GPL), has official translations, and in general is just "GPL, but better". That said, it doesn't quite close the "SaaS loophole". Or rather, it's somewhat easily circumvented as the EUPL allows combining your code with other copyleft "compatible licenses" and then redistributing all of this combined work under the "compatible license". These compatible licenses include the GPL and LGPL.
For my project I removed these licenses from the list of "compatible license", so technically it's not "EUPL 1.2", although it's close enough... I brought this up with one of the authors of the EUPL a few years back, and they felt it was fine as-is, but I still wish it would allow things to be a bit more flexible in this regard.
Still, I think EUPL is an excellent replacement for the GPL. But AGPL is a bit more complex. I still prefer my "EUPL 1.2 Martin flavour" because IMHO the AGPL is a horrendously written license and the text is just atrocious even by legalize standards.
It sees very little usage unfortunately; last time I checked my project was the only one in all of the Void repo to use EUPL :-/
For my project I removed these licenses from the list of "compatible license", so technically it's not "EUPL 1.2", although it's close enough... I brought this up with one of the authors of the EUPL a few years back, and they felt it was fine as-is, but I still wish it would allow things to be a bit more flexible in this regard.
Still, I think EUPL is an excellent replacement for the GPL. But AGPL is a bit more complex. I still prefer my "EUPL 1.2 Martin flavour" because IMHO the AGPL is a horrendously written license and the text is just atrocious even by legalize standards.
It sees very little usage unfortunately; last time I checked my project was the only one in all of the Void repo to use EUPL :-/
Which of your projects uses your modified license? That sounds like it could be just right for a project I'm working on.
Edit: Reading up more on it, it sounds like modifying the license isn't allowed. It's explicitly called out in section 3.7 of their guidelines. [0] Also, I didn't see anything in their guidelines that would help with the "SaaS loophole", unless you are referring just to the source availability as the loophole.
[0]: https://joinup.ec.europa.eu/sites/default/files/inline-files...
Edit: Reading up more on it, it sounds like modifying the license isn't allowed. It's explicitly called out in section 3.7 of their guidelines. [0] Also, I didn't see anything in their guidelines that would help with the "SaaS loophole", unless you are referring just to the source availability as the loophole.
[0]: https://joinup.ec.europa.eu/sites/default/files/inline-files...
[deleted]
For anyone wondering: "New provisions cover the Application service provider loophole of software distribution: Distribution and/or Communication (of software) includes providing on-line "access to its essential functionalities"."
See: https://en.wikipedia.org/wiki/European_Union_Public_Licence
See: https://en.wikipedia.org/wiki/European_Union_Public_Licence
It is interesting that the EU institutions started using #EUVoice (Mastodon) [0] and #EUVideo (Peertube) [1] on the Fediverse, both AGPL-licensed.
[0] https://social.network.europa.eu
[1] https://tube.network.europa.eu
[0] https://social.network.europa.eu
[1] https://tube.network.europa.eu
In light of Terraform/HashiCorp's license change recently, how "open source" should we consider companies like this?
Currently their GitHub repo is licensed under an open-source Mozilla license [1]. But contributors also have to sign a CLA [2] which perhaps (?) allows the company to re-license the work like HashiCorp did? Should we now consider companies like this to be "open source for the moment"?
[1] https://github.com/frain-dev/convoy [2] https://cla-assistant.io/frain-dev/convoy?pullRequest=1362
Currently their GitHub repo is licensed under an open-source Mozilla license [1]. But contributors also have to sign a CLA [2] which perhaps (?) allows the company to re-license the work like HashiCorp did? Should we now consider companies like this to be "open source for the moment"?
[1] https://github.com/frain-dev/convoy [2] https://cla-assistant.io/frain-dev/convoy?pullRequest=1362
Open source is about the license out, please don't try and add more implied meanings to the word. It's getting ambiguous fast enough.
How about "open to contributions" or "open governance"?
How about "open to contributions" or "open governance"?
> Open source is about the license out
Could you clarify what you mean here? Is "out" a typo?
Could you clarify what you mean here? Is "out" a typo?
"outbound" is the usual term I think, the license terms under which users get the product. There is no requirement on the "inbound" terms, what you have to do to get the project to make or accept the changes your request.
E.g. "inbound=outbound" is a common model for contribution [1], a short way of saying that contributions are licensed by their author under the same conditions that the project is available to users. But that has nothing to do with whether a project is open source.
[1]: Example in GitHub ToS: https://docs.github.com/en/site-policy/github-terms/github-t...
E.g. "inbound=outbound" is a common model for contribution [1], a short way of saying that contributions are licensed by their author under the same conditions that the project is available to users. But that has nothing to do with whether a project is open source.
[1]: Example in GitHub ToS: https://docs.github.com/en/site-policy/github-terms/github-t...
Thanks! That makes a lot of sense.
My original point wasn't really about the inbound/outbound distinction. It was that these companies can claim they're based on open source, but then N years down the line pull the rug out from underneath us all and re-license their code to be not open source, as HashiCorp recently did. I think this is qualitatively different from e.g. the Linux kernel where we are guaranteed it will be open source in perpetuity.
My original point wasn't really about the inbound/outbound distinction. It was that these companies can claim they're based on open source, but then N years down the line pull the rug out from underneath us all and re-license their code to be not open source, as HashiCorp recently did. I think this is qualitatively different from e.g. the Linux kernel where we are guaranteed it will be open source in perpetuity.
"perpetuity" is a weird word, a company can go out of business or discontinue a product entirely. Re-licensing is strictly better than those options.
[deleted]
I really love the sudden surge of open sources businesses coming out of YC and in general. I share some of the same sentiments in the post, having open sourced my SaaS business of 7 years earlier this year. One of my main driving forces was market pressure from enterprises wanting to self-host. One of the other drivers was my bus-factor of 1, as was longevity as you mentioned. Time will tell if the distribution side of things will ring true for my business, but I'm hoping it will judging by initial growth i.r.t. CE.
I wrote more about my "whys" here [0] if anybody is interested in a similar post.
[0]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/
I wrote more about my "whys" here [0] if anybody is interested in a similar post.
[0]: https://keygen.sh/blog/all-your-licensing-are-belong-to-you/
FYI, the license you chose doesn't seem like it would meet the Open Source Definition.
https://opensource.org/osd
https://opensource.org/osd
[deleted]
Well said, Subomi. I’d like to see more open source companies be public about how they think about open source as a strategic decision (admittedly, I could do better about this myself).
I think Vercel / Next.js and Automattic / Wordpress are great examples of aligning value to the business while also creating (and not capturing) a bunch of value to users of the open source project. As a result of leaving some value on the table for users, both projects have a thriving plugin/extension community that wouldn't exist if they were closed-source or confined to a single vendor. Likewise, I'm more likely to start a Next.js project knowing that I can host it anywhere, even though my default is to use Vercel.
I think Vercel / Next.js and Automattic / Wordpress are great examples of aligning value to the business while also creating (and not capturing) a bunch of value to users of the open source project. As a result of leaving some value on the table for users, both projects have a thriving plugin/extension community that wouldn't exist if they were closed-source or confined to a single vendor. Likewise, I'm more likely to start a Next.js project knowing that I can host it anywhere, even though my default is to use Vercel.
Paul, please write the article. I *want* to read it.
Hard agree. It's why I also believe that more & more companies will be more strategic with their licensing choice from the beginning. The common wisdom is to give it all away and grow at all costs, then switch licenses when there's brand value and the business needs revenue. This is poor because the license changes aren't bad in themselves because they still enable the individual developer to take enormous benefits, but they come with significant disadvantages like community drama, bad pr etc.
Hard agree. It's why I also believe that more & more companies will be more strategic with their licensing choice from the beginning. The common wisdom is to give it all away and grow at all costs, then switch licenses when there's brand value and the business needs revenue. This is poor because the license changes aren't bad in themselves because they still enable the individual developer to take enormous benefits, but they come with significant disadvantages like community drama, bad pr etc.
It is quite intriguing that after four decades [1] it is not particularly clear why individuals and organizations adopt "open source" (in one of its many forms). Yet somehow it keeps growing as tangible reality and is now possibly irreversible.
There have been countless arguments for motivations, benefits (short and long term), sustainable business models etc., with various degrees of plausibility but in general rather vague, anecdotal and subjective.
What is missing is not reflection on the phenomenon by its practitioners (or others in the tech domain) but the sharp, objective and comprehensive eye of scholars with legal and economic expertise (and by now, also a knack for tech history).
Understanding the dynamics of "open source" (in quotes again, because of its wide and evolving range of manifestations) is quite important. E.g., there are many domains that seem completely allergic to it, for reasons that are as unclear as the reasons for success in other areas.
In any case, while techies are taking it for granted, it is one of the most remarkable social phenomena of recent times. There aren't that many examples of large scale cooperation / coopetition of complete strangers across the planet, working on very concrete and useful tools.
[1] lets take the GNU project as the nominal start of the open source era https://en.wikipedia.org/wiki/GNU_Project
There have been countless arguments for motivations, benefits (short and long term), sustainable business models etc., with various degrees of plausibility but in general rather vague, anecdotal and subjective.
What is missing is not reflection on the phenomenon by its practitioners (or others in the tech domain) but the sharp, objective and comprehensive eye of scholars with legal and economic expertise (and by now, also a knack for tech history).
Understanding the dynamics of "open source" (in quotes again, because of its wide and evolving range of manifestations) is quite important. E.g., there are many domains that seem completely allergic to it, for reasons that are as unclear as the reasons for success in other areas.
In any case, while techies are taking it for granted, it is one of the most remarkable social phenomena of recent times. There aren't that many examples of large scale cooperation / coopetition of complete strangers across the planet, working on very concrete and useful tools.
[1] lets take the GNU project as the nominal start of the open source era https://en.wikipedia.org/wiki/GNU_Project
Open source also serves as a "defense strategy" for larger companies whose core business does not directly / indirectly depend on commercializing its open source project(s). They in turn serve more like hedges.
For example, Meta with PyTorch in context of the machine learning tooling space. PyTorch is probably strategically important for them as they do not have a cloud business. The other large competing deep learning framework is Tensorflow, designed and open sourced by Google but also owns a cloud business (GCP). They also have in-house AI accelerators like TPUs. Microsoft didn't really have a deep learning framework, but they have ONNX, and is now using ONNXRuntime as an on-ramp to their cloud business (Azure).
If Meta wants to continue doing ML, and all the other cloud players jacked up their prices, that's gonna hurt Meta's operating costs. So it's still "cheap" to have hedged against such a scenario. All these on top of upsides like developer marketing etc.
For example, Meta with PyTorch in context of the machine learning tooling space. PyTorch is probably strategically important for them as they do not have a cloud business. The other large competing deep learning framework is Tensorflow, designed and open sourced by Google but also owns a cloud business (GCP). They also have in-house AI accelerators like TPUs. Microsoft didn't really have a deep learning framework, but they have ONNX, and is now using ONNXRuntime as an on-ramp to their cloud business (Azure).
If Meta wants to continue doing ML, and all the other cloud players jacked up their prices, that's gonna hurt Meta's operating costs. So it's still "cheap" to have hedged against such a scenario. All these on top of upsides like developer marketing etc.
Open sourcing Pytorch was also a human resources decision. Big tech learned this lesson somewhere around 2014, that whatever problems they solve, other companies will have 5 years down the line and if they don’t open source their solutions someone else will release the industry defining standard and meta & co will have trouble hiring people for their handrolled solution 15 years down the line.
IIrc some spotify engineer said in an interview once that this was a big reason behind them open-sourcing backstage.
This strategy is called Commoditizing Your Complement [0].
[0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
[0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
> If Meta wants to continue doing ML, and all the other cloud players jacked up their prices, that's gonna hurt Meta's operating costs
How so? Meta is not running AWS/GCP/Azure.
How so? Meta is not running AWS/GCP/Azure.
Elephant in the room: People looking for open-source solutions are not looking to spend money, it's usually the opposite. If you want to build a business around open-source you should keep in mind, that your users are not your customers. What individual software developers want is different what enterprises want to pay for. Focus on the latter
It's the freemium model, which has always required a sufficient conversion rate from free to paid to work.
That doesn't mean you should ignore what your free/OSS users want though. Today's hobbyist OSS user may be hired at a big company tomorrow and introduce everyone there to your product.
That doesn't mean you should ignore what your free/OSS users want though. Today's hobbyist OSS user may be hired at a big company tomorrow and introduce everyone there to your product.
Last week, I talked to a VC, who's invested in a pretty popular open-source startup. They have huge issues converting oss users > paying businesses
That sounds like a business/value problem not necessarily an open source problem. People won't pay for something if the free /OSS version meets all of their needs. That's why an "open-core" business model works so well. Open core also allows you specifically target businesses with specific features.
Sure, it's a common problem with freemium. When freemium products fail, it's often for that reason. But there are also countless examples of freemium/open-core products succeeding.
What other problem would they have? A close-source companies biggest issue is converting non-paying to paying customers yeah?
"People looking for open-source solutions are not looking to spend money, it's usually the opposite."
I don't think that's true. In previous positions where I've had significant influence on budget spend I've still favored open source solutions because they make more sense from a risk point of view: should the vendor fail, the product has a solid chance of continuing to be useful.
I don't think that's true. In previous positions where I've had significant influence on budget spend I've still favored open source solutions because they make more sense from a risk point of view: should the vendor fail, the product has a solid chance of continuing to be useful.
It depends. I'd rather go with a venture-baked open-source solution rather than something made by one person in his free time
I'm not sure what point you're trying to make here except some people/companies have different priorities -- and if that's the case then there's room for both VC backed startups and smaller open-source projects.
I used to believe in the fancies of the communities I was apart of I thought they represented reality. Everyone talked up small iPhones, Linux on the Desktop, People paying/donating for FOSS, etc. But actually my community really just reflected a small sliver of reality. Even at that, more than a few folks were just talking about topics they wish were true, or they wish that they had done.
Convoy being a VC funded company
I think the mission for Conoy is to grow, grow, go public, increase shareholder value. Or these days, perhaps build, grow and make actual real profits.
not
"" At Convoy, our mission is simple; we genuinely want to put our technology into the hands of as many engineers as possible without having to worry about long sales cycles, data compliance issues, and being constrained to your immediate network & friends. ""
I think the mission for Conoy is to grow, grow, go public, increase shareholder value. Or these days, perhaps build, grow and make actual real profits.
not
"" At Convoy, our mission is simple; we genuinely want to put our technology into the hands of as many engineers as possible without having to worry about long sales cycles, data compliance issues, and being constrained to your immediate network & friends. ""
Though as an end user I love open source - I love it because it’s free, but you’re not going to necessarily build a business off people who like free stuff unless it involves monetizing them another way (ads, getting them to give you labor for free, etc).
Open source aside I wish there were some improvements on doing a highly available self hosted setup. I’m talking plugging 5 machines into a router and power and it just works. Auto healing, redundant backups, etc.
Open source aside I wish there were some improvements on doing a highly available self hosted setup. I’m talking plugging 5 machines into a router and power and it just works. Auto healing, redundant backups, etc.
I find "open core" or source-available (with license allowing self-hosting and custom modifications) to be a good middle ground.
It allows potential users to quickly try out the solution and prove its worth without having to first go through a (often months-long in big companies) procurement process.
It also allows users to understand how the system works internally which can fill gaps in documentation or cover use-cases the original developer hasn't thought of.
It can also allow them to fix bugs/edge-cases (that may not be in upstream as they are specific to a niche use-case) or to tweak the software to better fit their infrastructure.
Finally being self-hostable automatically makes the software suitable for secure, potentially air-gapped environments or allows the software to be deployed closer to where the rest of the infrastructure is.
It allows potential users to quickly try out the solution and prove its worth without having to first go through a (often months-long in big companies) procurement process.
It also allows users to understand how the system works internally which can fill gaps in documentation or cover use-cases the original developer hasn't thought of.
It can also allow them to fix bugs/edge-cases (that may not be in upstream as they are specific to a niche use-case) or to tweak the software to better fit their infrastructure.
Finally being self-hostable automatically makes the software suitable for secure, potentially air-gapped environments or allows the software to be deployed closer to where the rest of the infrastructure is.
Disagree on source-available... if the upstream business dies, source available doesn't necessarily allow you to make adjustments or fix bugs should that upstream company go under, or just stop supporting the application/library/service you depend on.
You at least have the technical possibility to do so - not the case with closed-source or even cloud-based systems. It may be a breach of the license, and it will be up to you to weigh the cost of potential litigation against the cost of stopping using the software immediately.
Also note that fixing bugs/making adjustments doesn't mean releasing them - the latter may be a problem with some companies, but it's unlikely anyone would care (nor know about) if you do the former internally.
Also note that fixing bugs/making adjustments doesn't mean releasing them - the latter may be a problem with some companies, but it's unlikely anyone would care (nor know about) if you do the former internally.
What "source-available" license doesn't allow you to do that via a fork? I'd love to know.
ELv2 allows it. BUSL allows it. SSPL allows it. Apache Commons allows it.
People diss these licenses and they don't even understand them.
ELv2 allows it. BUSL allows it. SSPL allows it. Apache Commons allows it.
People diss these licenses and they don't even understand them.
My biggest familiarity with "source available" was some of the .Net stuff from MS before they fully embraced FLOSS for .Net language/platform development. Which was iirc, a look, but don't touch kind of thing.
If you can fork and reuse, then "source-available" is probably a poor term for said license.
If you can fork and reuse, then "source-available" is probably a poor term for said license.
> If you can fork and reuse, then "source-available" is probably a poor term for said license.
I agree. Yet projects using said licenses get shamed into adopting the term "source-available" even though it doesn't fit, while "open-source" actually makes more sense in terms of communicating freedoms. It's all so ridiculous. Things need to change.
I agree. Yet projects using said licenses get shamed into adopting the term "source-available" even though it doesn't fit, while "open-source" actually makes more sense in terms of communicating freedoms. It's all so ridiculous. Things need to change.
To be fair, "source available" could also mean a fully custom license, closer to a typical proprietary closed-source license, except with "btw here's some source code, but you're not really allowed to do anything with it".
Even in the above scenario, source-available is still better because you at least have the technical possibility of doing something with it, at the cost of potential litigation for breach of license.
Even in the above scenario, source-available is still better because you at least have the technical possibility of doing something with it, at the cost of potential litigation for breach of license.
Yes, in theory. But in practice, I haven't seen a popular "source-available" license that limits your ability to fork. So making a blanket statement like that is wrong in practice, but people still tout it. That's the problem with the term "source-available" and why a lot of companies using these licenses avoid the term altogether.
But if you say "open source" instead of "source available" then you get the OSI folks flaming you for not comforming to the definition. It's a lose-lose situation.
> I wish there were some improvements on doing a highly available self hosted setup. I’m talking plugging 5 machines into a router and power and it just works. Auto healing, redundant backups, etc.
I do too! I'm building an open-source system designed for end user self-hosting and one of my goals has been making it as easy as possible to self-host. The two biggest are DNS management and Router port forwarding. I can give you a script that turns a Raspberry Pi into a fully-functional server, but you still need to configure your domain to point to your house, and configure your router to point to the Pi.
These require two different solutions. The first would be something like Oauth2 for DNS. I've spoken with the guy running TakingNames who trying to do that, DomainConnect[2] is another approach, but the requirement for service preregistration kills it for consumer self-hosting.
For port forwarding, I think we need a self-hoster's router. Something with (at a minimum) a better UI for doing SSL termination and reverse proxy without asking you to understand and nginx config file. Bonus points if a self-hosted service can discover the router and use an Oauth-type flow to do it's own configuration.
Once these exist it becomes much more feasible to have a service which does auto fail-over, or redundant backups, etc.. in your basement/living room without additional configuration.
[1]: https://takingnames.io/ [2]: https://www.domainconnect.org/
I do too! I'm building an open-source system designed for end user self-hosting and one of my goals has been making it as easy as possible to self-host. The two biggest are DNS management and Router port forwarding. I can give you a script that turns a Raspberry Pi into a fully-functional server, but you still need to configure your domain to point to your house, and configure your router to point to the Pi.
These require two different solutions. The first would be something like Oauth2 for DNS. I've spoken with the guy running TakingNames who trying to do that, DomainConnect[2] is another approach, but the requirement for service preregistration kills it for consumer self-hosting.
For port forwarding, I think we need a self-hoster's router. Something with (at a minimum) a better UI for doing SSL termination and reverse proxy without asking you to understand and nginx config file. Bonus points if a self-hosted service can discover the router and use an Oauth-type flow to do it's own configuration.
Once these exist it becomes much more feasible to have a service which does auto fail-over, or redundant backups, etc.. in your basement/living room without additional configuration.
[1]: https://takingnames.io/ [2]: https://www.domainconnect.org/
Open source software deserves celebration. Its impact on the world is profound and transformative. Recently, I began porting the 3D Gaussian splatting paper to C++ and CUDA with an aim to optimize the training speed of such models. This endeavor was only possible because the original authors open-sourced their work. The feedback has been encouraging, and I feel that I'm making a difference—perhaps even more than in my regular job. That said, it's essential to remember that contributing to open source, while rewarding, can be demanding if it's not your full-time occupation. Yet, through such efforts, we ensure these tools remain freely accessible and aren't monopolized by corporations.
I provide you the link to this GitHub project in case you are interested.
https://github.com/MrNeRF/gaussian-splatting-cuda
I used to open source every single thing I built. But recently, I stopped doing that because now I build everything as a single monorepo. All of my completely disconnected side project ideas are all in one repo and I'm much more happy being able to keep this like dependencies up to date in one place instead of having a different repo per project.
I would like to go back to open sourcing all things I play with but maybe I need to find a repo structure and tooling that would make that more sustainable.
I would like to go back to open sourcing all things I play with but maybe I need to find a repo structure and tooling that would make that more sustainable.
have a look at git subtree?
Honestly? I personally care very little whether or not something is open source at this point in time. Code bases have become so large that there’s little benefit to me other than self-hosting, and there are few things I care to self-host. The main argument I would make is that companies should, at the very least, open source everything before shuttering. If you’re going out of business, allow your former customers to maintain themselves what you’re no longer going to maintain yourself.
The real question is about contingency planning. Open source means you have the option to host yourself, but like you say that could be a lot of hassle, or more work than just switching to another closed source SaaS.
There are a few factors. If the space is competitive and there is an established API/protocol, it probably doesn't matter. Think Wordpress hosting, Email, renting VMs etc.
If it is open source and widely adopted - e.g. Linux, Redis, Kubernetes etc. then you know that thing is going to be supported forever. Although with the slight risk of a Terraform/Moq type issue.
But then you have open source and widely adopted with shifting APIs that generate more work - e.g. React.
Then you have these small companies that open source on YC with a 1-1 mapping between repo and corporation. If the corp goes under, the repo may go stale.
The decision as to the expected longevity and migration pain depends on a lot of factors. It is sort of intuitive. But open sourceness (and license freeness) is just one factor.
There are a few factors. If the space is competitive and there is an established API/protocol, it probably doesn't matter. Think Wordpress hosting, Email, renting VMs etc.
If it is open source and widely adopted - e.g. Linux, Redis, Kubernetes etc. then you know that thing is going to be supported forever. Although with the slight risk of a Terraform/Moq type issue.
But then you have open source and widely adopted with shifting APIs that generate more work - e.g. React.
Then you have these small companies that open source on YC with a 1-1 mapping between repo and corporation. If the corp goes under, the repo may go stale.
The decision as to the expected longevity and migration pain depends on a lot of factors. It is sort of intuitive. But open sourceness (and license freeness) is just one factor.
I never self host out of pure laziness. I like open source because I know (at least theoretically) that I can go in and fix something with a PR in a codebase I don’t “own”.
I've fixed like 2 things in projects I've used ever, I kinda suck as a contributor. But the indirect benefits I get from others being able to contribute to these projects is immense.
I've fixed like 2 things in projects I've used ever, I kinda suck as a contributor. But the indirect benefits I get from others being able to contribute to these projects is immense.
Fix, or just understand.
There is "documentation" and there is documentation.
And the real documentation is always the code.
There is "documentation" and there is documentation.
And the real documentation is always the code.
Open source creates the largest possible market share for the project.
Those doing most of the code contributions will miss out on monetizing a lot of this market. But it's better to monetize 10% of a market that is 100x bigger than monetize 100% of a market that is 100x smaller. Even if someone else isn't contributing much and is monetizing another 1% of the market.
I am pro-open source, I contribute back to projects, I've been doing this since the 90s. I'm going to gently push back a little bit on this:
> But it's better to monetize 10% of a market that is 100x bigger than monetize 100% of a market that is 100x smaller.
The piece to really think about is the support burden. Yes, with your numbers, you've monetized 10x net more users. But you have 100x more users who think you owe them free tech support, and if you are sufficiently curt while telling them "I don't care if you're having problems, the people who pay me are happy. If you want help, you too can pay me", you can quickly end up with a much smaller market than if you just had a much smaller happy set of closed-source users to being with.
Open Source is amazing. I wouldn't in a million years want to be the maintainer of a large open-source project. The people who do that without burning out deserve sainthood.
> But it's better to monetize 10% of a market that is 100x bigger than monetize 100% of a market that is 100x smaller.
The piece to really think about is the support burden. Yes, with your numbers, you've monetized 10x net more users. But you have 100x more users who think you owe them free tech support, and if you are sufficiently curt while telling them "I don't care if you're having problems, the people who pay me are happy. If you want help, you too can pay me", you can quickly end up with a much smaller market than if you just had a much smaller happy set of closed-source users to being with.
Open Source is amazing. I wouldn't in a million years want to be the maintainer of a large open-source project. The people who do that without burning out deserve sainthood.
You are talking about unmonetized open source (which I agree with you about). But the context of this conversation is companies monetizing open source. I have been in both situations and it wasn’t a problem when at the company monetizing.
How does being open source free a company from data compliance issues?
> ... without having to worry about long sales cycles, data compliance issues
which may or may not be associated with this part:
> ... and try to justify it with something-something data privacy.
> ... without having to worry about long sales cycles, data compliance issues
which may or may not be associated with this part:
> ... and try to justify it with something-something data privacy.
It's an interesting question, but it's the opposite of the one I usually ask.
Software should be open source. "Why try to monetize?" would be the question I'd ask myself.
Software should be open source. "Why try to monetize?" would be the question I'd ask myself.
Thought this was great - especially being so up front about the value of distribution.
I wrote a post about the very same meetup, but note distribution is not one of our "why open source" answers https://www.medplum.com/blog/yc-oss-faq - perhaps we are alone in this regard
https://github.com/medplum/medplum
I wrote a post about the very same meetup, but note distribution is not one of our "why open source" answers https://www.medplum.com/blog/yc-oss-faq - perhaps we are alone in this regard
https://github.com/medplum/medplum
I looked into this recently in relation to AI models, and had the following list for reasons companies (and ICs to some extent) open source. It's my own post but I think it's on topic here: http://marble.onl/posts/motivations_for_open_source.html
Name recognition
Community contribution
Collaboration
Building a user base
Creating a standard
Name recognition
Community contribution
Collaboration
Building a user base
Creating a standard
I described a checklist for open source vs fake open source evaluation
https://blog.oss.fund/p/a-framework-for-open-source-evaluati...
https://blog.oss.fund/p/a-framework-for-open-source-evaluati...
Feel the same way with integralapi.co – we'll be going open source very soon but want to make sure we have everything "open source ready".
Can't give out code that can't be exposed to the public.
Can't give out code that can't be exposed to the public.
Love the website design, but don't quite understand what it is and what problem you're trying to solve?
Open source allows other Open companies to train their models.
[deleted]
Because Free Software gives to much freedom to users.
how do you integrate convoy with twilio? it seems twilio webhook needs custom response based on event e.g record call.
You can configure a custom response on every source configured on Convoy.
Why male modela?
Deja vu from the late 1990s
It’s interesting to see how “being open source” has become the new “freemium” GTM model, but with significantly more downsides for the vendor.
E.g., now you don’t even know who’s using your product, how to collect their feedback nor who to contact to convert them to paid.
E.g., now you don’t even know who’s using your product, how to collect their feedback nor who to contact to convert them to paid.
> 92% of SaaS companies fail
then for gods sake stop creating them!
also what has this to do with foss?
then for gods sake stop creating them!
also what has this to do with foss?
1. I want organizations (initially newsrooms that care about data journalism, but rapidly growing beyond that) to be able to trust the product. The default result of 95% of startups is to go out of business, and going all-in on a product that then blinks out of existence is bad! When I'm selecting a vendor this is a thing I always consider, so I'd like my customers to feel confident that they have the ultimate escape hatch - run it yourself - should they ever need it.
2. Newsrooms in particular have learned this lesson before, many times over - and not just for startups. Remember Google Fusion Tables? https://en.wikipedia.org/wiki/Google_Fusion_Tables That's just one relatively recent example.
3. Datasette is an ecosystem play. There are over 100 plugins already - https://datasette.io/plugins - and I hope for there to be thousands more. Developers don't invest nearly as heavily in building and releasing plugins for closed-source platforms.
4. Open source is a way for me to punch _way_ above my weight. I can have a much larger impact on the world by participating in open source, compared to if everything I'd been building had been closed.