Why Open Source?
getconvoy.io
getconvoy.io
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.
Implementing billing and setting pricing is next on my TODO list!
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.
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.
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.
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.
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 (:
Trust comes from building a healthy ecosystem of users, which ultimately comes from building a good product.
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).
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.
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.
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).
I learned a lot in that time.
It’s closed source now.
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 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 :-/
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...
See: https://en.wikipedia.org/wiki/European_Union_Public_Licence
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
How about "open to contributions" or "open governance"?
Could you clarify what you mean here? Is "out" a typo?
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...
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.
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/
Hey, I read your post and I'm a big fan of keygen. I plan on self-hosting it too for Convoy soon. :)
Let me know if you ever need anything!
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.
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.
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
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.
How so? Meta is not running AWS/GCP/Azure.
[0] https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/
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.
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.
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. ""
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.
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.
ELv2 allows it. BUSL allows it. SSPL allows it. Apache Commons allows it.
People diss these licenses and they don't even understand them.
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.
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.
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.
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 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'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.
There is "documentation" and there is documentation.
And the real documentation is always the code.
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.
> 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.
> ... 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.
Software should be open source. "Why try to monetize?" would be the question I'd ask myself.
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
Name recognition
Community contribution
Collaboration
Building a user base
Creating a standard
https://blog.oss.fund/p/a-framework-for-open-source-evaluati...
Can't give out code that can't be exposed to the public.
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.
then for gods sake stop creating them!
also what has this to do with foss?