In our case, the Graphistry team loves and breathes OSS every day. We helped start what became the massively popular Apache Arrow and Nvidia RAPIDS projects, release our Python & JS clients as OSS, and PyGraphistry[AI] is a graph Swiss army knife, including tools like GFQL the only embeddable & dataframe-native & GPU-accelerated implementation of the Cypher graph query language..

... But we sustainably grow primarily by selling cloud/on-prem self-hosting licenses to enterprises, govs, and data companies to our GPU graph viz server. Thankfully, after years of grinding, that business is growing well. As a natural experiment, our alternate SaaS hosting revenue does support a tiny team... but not the majority of our team. Most of our innovation cycles would disappear without our self-hosting license revenue.

There's some cross of winning lottery ticket, SaaS market profile, and technical defensibility getting missed in the article that I can't put my finger on. Our launches of Louie.AI + GFQL are changing the OSS viability story in our particular case (I'd love to chat w successful founders here!), so I'm not saying it can't work, but our experience to get to this point makes me worried for new founders reading the article.

[1] https://graphviz.org/

Then again, we could make the software worse to trigger higher support hours, as complained by others in the thread about some OSS companies. Or really lean into it, going to full-blown consulting. However, switching to a consulting business has all sorts of negative externalities that can easily destroy the strengths and joys of a product culture. We actually do provide a growing side of professional services and roadmap acceleration for Graphistry & louie.ai (graph viz, graph AI, genAI, for data-intensive operational / investigative scenarios). By having our product licensing revenue the majority, we get to make sure there is stronger positive mutual alignment between us and our users, and our software and their long-term mission.

As another natural experiment, I was interviewing someone from a company in the same space a few days ago that doesn't have this discipline. While our company is younger, our tech roadmap has been literally years ahead every year, and the software they deliver has no real upgrade path.. alignment helps when you care about your craft and customers. (And for HN'ers, it's a 5X+ on valuation multiple.)

- We do in fact operate multiple OSS repos. Despite their usage, most, as with most OSS in general, do not get significant code-based contributions. Our proprietary repos are even more complicated (e.g., distributed GPU code, webgl shaders, and "boring" enterprise bits), where we'd expect even less involvement. Instead, they see other values from the OSS community like easier bug reporting and, as you say, easier for folks to see if the tool is for them. Writeups like Supabases misses this nuance in practice, focusing just on the rarer lottery ticket scenario. (Which is natural to come from a marketing / devrel person that got hired after-the-fact: selection bias in action.)

- Our customers do pay for feature development even without the OSS

Most of all, as you say, maybe marketshare can grow! But in my original point, now that's counting on lightning to strike twice, once for OSS and then again for the company. That's a very big decision when many people's lives -- and their families -- are making bets here. We're actually reexamining the economics of this question now that much more is known and we have more stability. Much trickier than the blogpost makes out!

For your open source repos, how much effort is put into inviting contributions and making it easy to contribute? Growing an open source community is a lot of work, and is a skillset apart from (but not always exclusive of) software development and business development. Many projects don't try, or don't do a good job of it. Some projects (may e most famously SQLite) openly state that they have no interest in outside contributions. (Its a legitimate choice, but the consequences are obvious).

Typically we get nice small contributions from devrel teams around connectors in their software, and junior data scientists newer to coding who we encourage to do examples instead of core code

We revisit this every year or two, and are overdue, thanks!

- People might criticize my messy/bad/unfinished code

- Hackers will find and exploit security holes

- Competitors will steal my Intellectual Property

I think they are missing a 4th item which is "Amazon/AWS will commercialise and sell a service based on my code and not pay me anything."

As someone who has created and maintained open source projects (most recently Willow[0]) for two decades I get a kick out of this.

Of course when interacting with users and feedback I keep it polite but in my head I'm thinking "You like to talk. I actually DID this. Shut up or submit a PR".

Surprise surprise they almost never do.

Keep actually producing and shake the haters off!

[0] - https://heywillow.io/

I also do consulting and advisory work in adjacent spaces so this is pretty much my lifelong dream - spend my other time just doing open source projects I think are interesting.

People seem to get really salty when companies change their license further down the line to prevent this.

I think a lot of people get salty when a company changes their license to a source available license but still try to call it open source and free ride on the goodwill that open source software engenders.

Don't call a license open source if it isn't and reasonable people will be fine with it.

People get salty because those license changes are from open source to source available (like the BSL).

Some of us (myself included) even consider licenses like the AGPL to be nonfree.

Free software can be used for any purpose, including competing with the original authors. If you can’t do whatever you want with the software, it’s not free software.

If you want to open source your software but you want to put restrictions on what people can do with it, then, well, you don’t want to open source your software (and IMO the free software community would be better off without your free software cosplay).

- being able to just read the source to figure out what's going on

- being able to fix bugs

- being able to add features I need

- being able to upstream those changes so others can profit and help maintain them

- being able to self-host the software

Open Source ticks all those boxes, whether it's on the "laissez-faire" end of the spectrum (BSD) or the "Stallman" side of the spectrum (AGPL). (though the more "Stallman" a license is the fewer situations where I can use it). But the BSL also ticks all those boxes. I get it's not as ideologically pure, but it still meets most of the ideals of the original open source/libre software movements.

What the BSL prevents me from doing is offering paid hosting for others, or offering a product that competes with it (e.g. if postgres would be BSL, supabase couldn't use postgres under the hood since the products kind of compete with each other).

https://mariadb.com/bsl-faq-adopting/

So the ability to self-host BSL code depends a lot on the chosen Additional Use Grant. I don't mind Hashicorp's, but the one publicly offered by MariaDB is pretty restricting.

1: https://www.hashicorp.com/bsl

Here are some others: https://github.com/search?q=%22Business+Source+License%22+%2...

In either case you don't have to pay for the software, can modify it however you'd like, and run it wherever you want. You just have to share the modified source code.

Stallman already carved out exceptions for "appliances" that had computer chips, like microwaves. Stalllman wanted is own general purpose computer to be libre, not freedom to control other people computers (Cloud).

I have two thoughts on what you bring up, the first is a story I remember about Stallman being really frustrated with firmware on a printer (not drivers on a “general computing” device). I think reading this story[0] should be reasonably self-explanatory and not require additional exposition or warrant in this HN thread.

My other thought is that increasingly, our “general computing” applications are moving to web apps / cloud apps, and not stored on our devices. So while you may be correct about RMS, and maybe he wouldn’t have cared today about the concerns AGPL addresses, I personally wonder that he would, and think its at least reasonable for many people to generalize his FSF philosophy to cover general computing experiences that aren’t hosted locally but are still part of the primary computing interface that we use to interact with our current general computing devices.

0: https://www.fsf.org/blogs/community/201cthe-printer-story201...

AGPL is an EULA that is additionally really badly written, especially compared to clarity of GPLv2-only.

> 13. Remote Network Interaction; Use with the GNU General Public License.

> Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

> Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License.

Section 13 only states that someone/something interacting over a network is considered a user (and that you can combine GPLv3 and AGPLv3 works). That is the only change compared to GPLv3. It does not otherwise change what rights the user has or what is considered a corresponding source (i.e. what the licensed work contaminates). Those are word for word identical between the GPLv3 and the AGPLv3.

If you have an issue with what rights/restrictions the AGPLv3 provides a user of the software, that issue is with the GPLv3, not the AGPLv3.

Yes, the AGPL was essentially intended to plug the SaaS (maybe it was still being called application service providers at the time) loophole seen by some whereby delivering a network service wasn't considered distribution--and therefore didn't trigger copyleft provisions--with the GPL (either v2 or v3).

A lot of work went into GPLv3 and a lot of legal niceties were added as well as the watered-down TiVoization language but really isn't a lot of practical difference between GPLv2 and v3.

Depending on the software, I agree it's not as good for me as free software, but it's not worthless.

Being selfish isn’t a good look, especially when starting out as free software (Docker Desktop, I’m looking at you).

I even strongly dislike actual free software releases with companies that have proprietary stuff alongside (so-called open core). It means that the people doing it don’t give a shit about software freedoms, otherwise they’d never consider releasing nonfree software. Mattermost is in this category (and further demonstrates their disdain for software freedoms by shipping nonconsensual spyware in their foss stuff and closing PRs that remove it).

It’s really shady to position yourself as an open source company and then release any proprietary software.

I imagine it's tricky (or at least unstable) to earn ones living working only for entirely open source companies, but maybe there are more opportunities out there than I'd realized.

I am personally responsible for at least 3-4 startups never making/releasing anything but open source stuff. I advocate for the basic idea of software freedom in all contexts.

Usually “business guys” try to interfere, but it’s almost always from the misguided idea that the code is somehow valuable. People get this weird idea that their source is worth money (it never is). Most companies are valuable because of their ability to execute, not their code (which is rarely reusable outside their org anyway, and even if it is, not in their market).

Think about it: if your code were valuable, how is it that a few people were able to make it from scratch in a few months? It’s obviously your staff who are valuable, not the code (which someone else could also make from scratch for low cost if they needed to, just like you did).

It’s the same misguided emotion that makes people think startup ideas are inherently valuable. It’s the ability to execute, not your so-called “intellectual property” that is where the value is.

I don't agree with you on that code isn't valuable – it varies by product complexity, essentiality of the software as part of the business, etc. – but in of itself is the distillation of solved problems, which generally takes years (not months) to work out.

Still, I appreciate you taking the time to break it down, and it's something I'll think about.

I’m currently looking for a new SWE position and I prefer places that have active open source projects.

I’d take less pay to work at somewhere that maintains and releases free software.

I'm coming more from a "build a company and feed your family" point of view but everyone has to balance their own priorities/ethical positions.

I guess at least if the license is set at the outset people can choose to engage or not, rather than having what they may percieve as a "rug pull".

Which definition of free do you use?

You may have valid criticism against AGPL but non-free isn't one. It's free according to the free software definitions and the open source definition. It's recognized as free by the two organisms providing relevant definition (OSI and GNU) and by all the relevant actors, including Linux distributions and even big proprietary companies (including GitHub).

I think you are misunderstanding the meaning of "for any purpose". It only applies to what you do with it when you run it. It does not mean you can do anything you want with the source code. It is very important to understand this aspect correctly when developing software or for a free software / open source enthusiast.

That's like saying a free society can only be free when individuals are free to do anything they want including harming/limiting freedoms of other individuals. Well, no, most free society limits your freedom to harm other people or bans you from limiting other people's freedom. The AGPL prohibits you from limiting other people's freedom.

I haven’t found a reason to deploy one yet. One use case I have seen is to have some sort of commercial/AGPL double distribution, perhaps with the AGPL release lagging behind.

But with AGPL, you now have to. Ensuring compliance is costlier.

previously on HN, https://news.ycombinator.com/item?id=31713525

Maybe the joke swoshed by me. :)

I was with you up until this point.

The only real limitation on the AGPL compared to the GPL is section 13 which states that you need to make the sources for said AGPL program available to any user who interacts with it. Otherwise the license is practically identical. Otherwise the license is essentially identical to the GPL.

If you diff the licenses, you'll see that other than section 13 and s/GPL/AGPL/g, the actual license terms are identical (if you diff sections 0-12, only the addition of the word Affero to the first line of section 0 will come up). The preamble and afterwords are different but they aren't actually part of the license (only the sections between the lines `TERMS AND CONDITIONS` and `END OF TERMS AND CONDITIONS`). As for the differences in those sections, the preamble provides context for why the license exists compared to the GPL and the afterwords provide a recommendation as to how to provide source access.

So in effect the AGPL is identical to the GPL with the addition of requiring that you make sources available to any user "interacting with it remotely over a computer network". Contrary to popular belief this doesn't mean you need to provide sources for everything that touches it over a network, just that anybody/anything that interacts with it over a network be granted access to the AGPL source (and corresponding sources). The requirement for what is considered part of corresponding sources is exactly identical.

That requirement:

> The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

TLDR: The only practical change in the licenses for a piece of hosted software is that under the GPL the user is the server operator/host and under the AGPL the user is the actual user/client. Whether a given piece of software gets "contaminated" by a AGPL work is no different than if said AGPL work was licensed under the GPL instead.

Mastodon et al prove it works.

Honestly, for considerable portion of its use, it works mainly because nobody looks too closely or trieso actually enforce it.

The other considerable portion was/is bait&switch schemes involving dual licensing and having developers sign copyright transfer forms to parent org, which benefits from selling commercial license when someone runs afoul of compliance.

Each tool has its use and serves its specific purpose. What works for Mastodon might not work for others trying to advance different goals.

In the end, the AGPL is huge but not a silver bullet.

The only real drawback is ensuring any outside contributions can be utilized this way, such as with a CLA.

[1]: https://pl.aiwright.dev/about/license/

It's really hard to make any money by giving your product away for free...

Even supabase is an awesome product but they needed $116M of external funding[2] to support their development which looks like unsustainable model for open source.

[1]: https://prismic-io.s3.amazonaws.com/sacra/fc6f34f9-d598-4b53...

[2]: https://www.crunchbase.com/organization/supabase

To my knowledge we don't have any competitor that takes XWiki and provides support and/or consultancy. I don't think it would be possible to freeride on our product because it would require expertise they would only have if they contributed to the project and it also requires brand recognition. We are of course the reference, people trust us because we are the main developers.

Many features have also been sponsored by customers so we do receive money to develop big parts of the product itself.

[1] https://www.xwiki.com/

[1]: https://xwiki.com/en/pricing/

In particular, the core code for dealing with LDAP is there [1], open source and gratis, and the paid app that provides a nice UI for it is... paid but also open source under LGPL and the code is here: [2].

You can actually clone the code, strip the license management, compile it and install it on your own instance, but people usually just pay and they also get support.

It's pretty much like OSMAnd Plus, which is paid on the Google Store, but the actual source code is still free software.

So yes, we actually sell free software (and free ≠ gratis has its full meaning with us), and it turns out convenience makes it so that it works out.

Usually organizations big enough to want to use LDAP can usually fork off a few bucks and will be glad to support us.

Of course it would be nicer if it were free and it's always a delicate balance to decide what should be a paid app / feature, but at least it's always open source , with all the relevant rights to users it implies: the right to take the code, adapt it and/or go find someone else if they are not happy with us.

As someone convinced that free software is the right way to do software, I think this is a sane way to fund free software, and good to take.

It's also way easier to handle than donation for an organization that would like to send us money, it's easy to justify.

[1] https://github.com/xwiki-contrib/ldap/

[2] https://github.com/xwikisas/application-activedirectory/

[1]: https://www.crunchbase.com/organization/ionic/company_financ...

Freeriding would break on the first tricky support ticket or the first feature you'd need in the product that isn't there yet. You get to know the product well enough if you start contributing and interacting with the main contributors, at which point you stop freeriding and you become a partner instead.

The other way to do this would be to get an agreement from the main developers so you can be supported on your consulting and support activities, in which case you also become a partner.

I tend to think both outcomes as beneficial to the main devs, who can always stop collaborating if it turns out they are not.

Now, if your product is something for which nobody needs support or consultancy, you risk having the MongoDB-Amazon issue.

...So, that is the problem isn't it?

Basically, well-written software and documentation are meant to reduce the amount of support and consulting needed by users. Assuming your point is true, then for a company that sells support and consultants, enriching documentation, etc. would be an action in direct conflict with its own interests, wouldn't it?

The MongoDB people are very passionate and have built a great software, documentation and user community... to the point where they no longer need to sell their own support. Therefore, it is my understanding that Amazon has decided to use their "support".

(If you're saying that it doesn't matter to the users if the company lives or dies when there is already functioning software and community, that may be true)

Yep, it is a risk, but it's also not applicable in every case. Now, I'm not an expert and I'm not sure what are the exact boxes to check to avoid the issue but we for sure don't have it. It is definitely something to carefully consider when creating an open source business. I guess Amazon wants to provide nice developer tools and improve its cloud offer to attract people to its cloud solutions, but our product is not for such developers. Amazon is not interested in providing support and consultancy for XWiki (we know this for a fact since they use XWiki and sponsored important features). It does not scale that well, unlike providing MongoDB.

> would be an action in direct conflict with its own interests, wouldn't it?

One could think this, but it's not actually the case. I guess we already have enough support work that's not related to a lack of documentation such that we don't need to increase it artificially. We are actually incentivized to reduce our support work. Companies will usually need to be reassured by a support contract in any case.

We are big users of the documentation ourselves and we have every incentive to write good documentation because of this. Lack of documentation actually increases our cost of operation, because all of a sudden, if you need to know something, you need to find out the relevant developers, who might have left (but probably not because people usually stay), and wait for their reply, or wait for someone to look into the relevant code.

There's also no policy of keeping any documentation secret. On the contrary, we are encouraged to publicly document what we do. So when we document, we do it publicly, except for internal processes.

Our documentation is far from perfect, but it's because of a lack of time or diligence, not because we are incentivized to keep documentation secret.

What's more:

- a good documentation is a good look for someone who seeks to adopt our product

- the same values that push us to do it the open source way pushes us to also publicly document things.

- when documentation is lacking or help is needed, you can always reach us on our public chat and our public forum, and the product team is in reality usually quite responsive. And so if the documentation is good, there are fewer questions to answer. Of course, there are limits, questions that look like support questions will be invited to talk to our support team. Unless someone else in the community does answer the questions for free.

USG has so many programs (eg NSF grants) for tech and the disjointedness of civil agencies, IC, and state govts means they end up procuring a dramatically large landscape of software. The regulatory and compliance bar to entry is not nearly as high as you think especially if you are teaming your first few contracts. It is solid, guaranteed revenue to fund your project for usually 3-5 year commitments, and usually massively profitable.

I wish more open source companies took advantage of this, because usually fully private sector companies will end up baking open source libraries into their project and sell it at gigantic markups, pocketing everything. eg: https://x.com/ssankar/status/1749202248700420587?s=20

When I was in govt I saw so much software that was basically open source maps + open source db for $12m. To give another frame of reference, I’ve seen OCR on PDFs carry a $2mm price tag, and a tool like weights & biases carry $30mm (all $ per annum).

There are even other incentives here beyond deploying software; for example prioritizing fixing certain bugs or security flaws in your software — eg IC would have paid big $$ for safetensors.

I’ll even highlight four ways Supabase could do this: - Cybercom (direct) - DOS (direct or teaming) - VA (thru a PWS) - direct to govcon software powerhouses

And three ways to do this: - cold email GS 14s/15s or equivalent - hire an ex-GS15 - find a solicitation that fits on SAM.gov then use GovPro.ai (white glove) or rogue (diy) to put together a response

From what I've seen, governments and startups typically don't go well together. By the time the government bureaucracy has finally approved the contract, most startups would already have been out of money.

Most are not like this, usually the government puts out solicitations (RFI/Q/Ps). They have a set deadline by which they have to answer your questions, a set deadline for bids, and a set deadline (usually 30d) by which they have to select someone.

You can also game this by emailing people around september, which is when they are getting ready to close their budgets. They need to spend any surplus, and I’ve seen many prominent civil agencies (won’t name and shame) throw around $1-2mm on a same-day contract with vague constraints.

- experience in the field (or agency-based past performance)

- clearance (usually public trust for civil, which can be as short as 1-2 week turnaround)

- citizen, US based, with data centers/software inside the US

There are stringent requirements for software the higher up you go (esp to DoD & then IC) but requirements most will meet and build towards while still making $$$. You don't need to have 20 TS/SCI engineers who have IAT L2 and IL6 infra with an ATO at the agency to start with (or even know what those words/acronyms mean), but a vertical in govt will naturally enable that over time.

If you want to get into the public sector, think small and wide, not all-in on the biggest one.

The most lucrative sector of government (in the world) is the US Department of Defense.

Not only are they incredibly bureaucratic and schedule-sensitive, they are obsessed with secrets.

My company has had people straight up tell us that they are comfortable using our managed service for that reason.

Unless you're implying that Supabase are for some reason deliberately releasing separate defective software to the open source community... to... convince users that using their commercial services is a good reliable option??? I can't really figure out how or why any business would go to the effort of doing this. It seems patently easier to be a legit open source company.

Assuming you're not implying the above & I've just misinterpreted... everything else in your comment paints Supabase in an eminently positive light.

I'm absolutely with you here but I think this is a matter of least worst situations: I still think an OSS corporation trumps a non-OSS corporation regardless.

> These days it's not unbelievable that they are doing it on purpose.

I think there's a bit of a leap between a company - at a management level - deciding to "go open-source" for mainly marketing/branding/image reasons & that same company actively endeavoring to make their open-source product deliberately worse.

It's still likely (& common) that profit incentive will lead to paid plans receiving more investment & QA than open-source offerings. But again, this is a least worst outcome imo. A semi-abandoned corporate OSS project isn't very different from a semi-abandoned personal individual OSS project - maybe even better as there will typically be less social reluctance to build a community fork.

Daily, you are bombarded with decisions for how to allocate resources. In each of those, do you lean towards the option that makes it easier to self host rather than spending those resources on other things?

There are systemic reasons for these systems to be underresourced - there's absolutely no need for theories about deliberately crippling OSS offerings.

Maybe it's not viable for commercial purpose, but status quo hurt open source software hard by a strong erosion of what to expect of it, without clear long term benefits for companies choosing such a scheme.

Distribution is an orthogonal concern. The fact that many existing things are nicely distributed is a pleasant bonus, not a necessary condition.

If the authors are using open source as a selling point and marketing relay for broad audiences, I think there is a moral obligation to.

For projects with little awareness, niche, or "just a hobby, won't be big and professional", yes sure, I would never think to have any opinion, nor bothering them.

It also allows developers to look at the code that's actually running, even if they don't run it themselves.

The open source part, especially it being Postgres, makes it possible for me to move away if I choose to do so, while picking and choosing the parts I want to keep. This ability was crucial for me, I would not have used Supabase otherwise.

If you look at Firebase for example, there are countless stories of how difficult it is to move away.

Even if I won't self host Supabase, I can just take my schema, take my data, and put it elsewhere fairly easily as all the postgres extensions and everything is open source. I have the ability to move away from Supabase completely, and people have done this successfully before (see https://news.ycombinator.com/item?id=36004925).

Some people do actually self host btw, and supabase is adding more options like hosting on Fly.io.

Besides this there are other advantages:

- I run Supabase locally for testing (using their docker images and CLI)

- We run Supabase in GH actions for automated testing and migrations

- I connect directly to the db, and use postgres tools for various things, backups, snapshots, db admin tasks.

- There are community clients for many different languages

Sure, it's also marketing, as these are all great benefits that really had a big impact on my decision to build on Supabase. Open source is more than just self hosting.

A lot of products we all use underwent complex business changes, but the Open Source ones still are here for us to use. MySQL had a tumultuous past and yet there is a very active version of it hanging around under a new business.

The marketing angle is for the company to leverage, but the open source nature of it is for the user.

It’s appreciated since SaaS on AWS wasn’t a possibility.

Realistically, it feels like the actual utility of an open-source project is based on:

1. it being educational: so everyone can look into its source & learn from its design pattern, etc, or build upon or borrow parts (eg to be modified) and to be used in their own projects - but the practicality of it will really depend on how decoupled and well-designed the system is

2. in favour of competition (so more possible start-ups / big corps can clone their systems/services) and as consumers we will obviously benefit from that

3. llm can access & train on its source code

I think point 3 is most interesting. And I’m also super curious how true point 2 is and to what extend

Point 1 is really cool too - esp when it is done wonderfully (Linux, React for example) but it really depends on so many levels

However this comment feels off:

> In software ideas are cheap. Value is almost always created in execution of ideas.

I've heard this phrase around things like "I have this cool idea for a startup - will you sign my NDA before I tell you about it?"

However, when you're open sourcing your software, you're not just providing an idea, but a significant portion of execution of that idea too.

Sure, code isn't the full execution - that expands to sales / marketing / support / etc.

However, the article is a little glib towards the value of the code, suggesting it's worthless without sales / marketing /etc. I don't think that's true.

Code is not worthless but it almost is without sales/marketing/talking to customers. If I could split the value, it would be 90% sales/marketing/customer validation and 10% code. I run a low 7 figure bootstrapped SAAS (not open source) and I can tell you that code is mostly shit anyway and keeps evolving.

The quoted and beloved open source projects are not good businesses: PostgreSQL, Python, Bitcoin, React

Mongo and Elastic are great, but exceptions. There are more successful closed source database companies than open source ones.

Open source companies are hard. However, they are super valuable for users.

Barring a discussion about whether or not a license is "open source", what matters is that these businesses asserted that commonly used licenses - (A)GPL, Apache, MIT,... - are leaving ample room for competitors to setup their own managed / hosted services and compete with them through scale (e.g. Amazon's Open Search offering undercutting ElasticSearch).

[1] https://blog.opensource.org/the-sspl-is-not-an-open-source-l...

But for me, answering the question as asked provides the path to answering the question as reworded. To me, the question as asked is about the nature of the software the company uses, not sells.

I personally will always choose an open source product over the alternative, even if I happily pay for support or just donate to support the project. Unfettered access to the source is fundamental to me, even for software I never intend to alter.

I know this seems to many like an extremist position. But I don't like the idea that I am not allowed to tear down my microwave or doorknob or transmission. I might never be able to put them back together in working order. Or I might be able to find a gear with a missing tooth and execute a $2 repair instead of a $90 replacement. Or I might invent a new frakenstein microwave with a tranmission.

Extending the featureset of a web server or understanding why my plugin is crashing the host app, etc. are important to me. I think they are important to society. So I hold on to my open source extremism. If you show me the hottest new tiny web server that can do HTTPS/4 with built-in AI in just 5Kb, I will be intrigued, but if it isn't open source, I'll stick with my current stack.

With this mindset, the software I produce is open source. And sometimes people pay me for it.

From my experience, for procurement people all of that (brand, community, team, DX) will matter close to 0 in comparison to compliance, etc, if you are going head-to-head with an existing supplier like Google.

It would be interesting to hear a story like this from a project of similar size that has $0 funding, has been founded in the last 5 years, has a fulltime team >1 and exists for 3+ years and still would recommend this approach. How are they making ends meet? Things like Redis simply don't happen anymore. At least; I haven't seen any. Hell, even trivial projects, like langchain, get in 10s of millions of VC and those would be my candidates for actually being able to do it as a few-man-band while getting in money via different sources.

All of my software is released as public domain (free software) and none of it is a successful open source project or community. Free software is first and foremost an ideology, and a practice or feature second.

Edit: forgot 'don't'

It wouldn't even take a tech giant like FAANG to outdo your project after forking your source. A medium-sized company could throw a dozen programmers on the project and their fork would surge ahead of the original with respect to features, support, and distribution. They could out-market you as well.

In most places in life this is valid, but in the developer community I disagree. Developers love talking shit about each others code.

Still yearly ritual here to bash the "Clean code" book.

> Toxic community members who complain about bad code instead of making suggestions to improve it are not the people you want in your community anyway.

If someone finds your code and goes out of their way just to shit on it, they can get fucked. I'd be handing out blocks for that.

However, I get their point for both cases. Looking at contributions gives a glimpse of that person. However with a grain of salt.

And the imposter syndrome is strong in public contributions. I get it, and agree with the article, don't worry.

I am working with a gov client at the moment so back to coding in the open again, and it is great. I am not worried that my quick one-line comment on a PR for a tiny repo is now public. Or pushed typos. It happens.

On the other hand if your product isn't good enough then the decision doesn't matter since it won't take off either way. :)

Would it make sense for Meta to open the codebase for facebook.com? Aside from studying/scrutinising the code, the only other thing you'd be able to do with it is to change the logo and try to compete with Facebook.

In this example, it's still probably not enough to disrupt them thanks to the social graph and infrastructure complexity. But you could imagine moments where even Meta gets nervous when anyone can start competing with feature parity from day one.

Over the long-term, it's more likely that Meta would want to keep some features private. It's also less likely that they would get lots of quality contributions back. If you're running a fb.com clone in production, you're likely trying to compete with them on some level. This leads to a weird relationship with the community and limited value for both sides.

Your users can just host their own version instead of paying you.

It seems like many OSS companies mitigate this by leaving out features from the OSS version or making the deployment more difficult than it should be. I’m not complaining, I think it’s fair, but this is the reality.

It’s funny how they don’t address this one, but instead they list “oh no my code isn’t pretty” as a valid complaint against going OSS. Who cares.

>Your users can just host their own version instead of paying you.

The main value in Supabase (the hosted service) is we do the hosting, maintenance, monitoring, compliance, security etc. which otherwise requires (expensive) in-house expertise.

This should be enough without needing to resort to deliberately leaving out features, and I think this generalizes to other products as well (sentry, plausible, the-open-source-strava-alternative, etc.)

For example, you can self-host WordPress if you want, and it's a perfectly capable product. But if you want to outsource the complexities around it, scale it easily, properly secure it, etc., it's worth considering using wordpress.com instead.

This model definitely leads to some perverse incentives.

Grafana and its ecosystem of apps are another example. Sure, you technically could host and maintain it yourself, but Grafana Cloud streamlines all of that, which is worth paying for. This doesn't mean that Grafana products are intentionally limited, but that the commercial product offers value added features some users are willing to pay for.

The fact that some companies take advantage of this model doesn't mean that the model itself doesn't work. They're just not good companies to begin with, and don't understand open source.

Do you shard and partition the DB? Do you introduce a message bus? Do you add a caching layer? What about k8s and Terraform and Helm vs simply creating a single VM?

These are all very different levels of complexity to standup and manage. Some require entire teams to manage them.

Regardless of intentions, there’s no “one-size-fits-all” solution to architecture and infrastructure decisions.

Don't do this. The OSS product needs to be as featureful as your commercial product. It's fine to offer some commercial value added features and services that would only be useful for enterprise customers, but these shouldn't be core features of the product. You can have priority support for your paying customers, but don't leave OSS users with "community support" only. At the end of the day, the company does need to make money to survive, but treat all your users with the same respect. If the product is good enough and solves a genuine problem, you won't have difficulties monetizing.

"If the product is good enough and solves a genuine problem, you won't have difficulties monetizing." is wishful thinking. Look at Elastic, MongoDB, RHEL and HashiCorp - all with amazing adoption - having trouble attracting paying customers to pay them over someone else and subsequently having to remove the ability of others to monetize their product.

Those are still service problems. If you as the author of the project can't build a solid moat around it that entices users to use your commercial service over someone else's, that means you haven't done a good job at it, and others have.

It's a difficult balance to keep OSS users happy, while also making the best commercial offering. Not many companies do this right. I think Grafana has done a solid job of monetizing the open core model. I struggle to think of others, but I'm sure they exist.

EDIT: Another example might be Automattic. I'm not a WordPress user, but AFAIK it has a very healthy open source community, and wordpress.com is _the_ place to use it commercially. Doesn't WP run something like half of all web sites?

Do you also struggle to think of businesses who are not OSS but successful? I think the list of non-opensource companies that became big is much, much larger - to the point I think it's fair to say successful OSS companies (from the perspective of making money, at least) are the extreme exception.

How do you figure this? Nobody will know the product, its users and their needs better than the original authors. They have a distinct advantage over any competitor who only offers a commercial wrapper around it. Not to mention that they have full control over the direction of the product, and can at anytime introduce a new feature their commercial service takes advantage of from day one. Their competitors could also fork the OSS product, but it's very likely that the OSS userbase stays with the original authors.

Again, for this to work the authors need to be both great OSS stewards, and great business leaders. Not many companies do this correctly.

> I don't think that's enough, especially if the other company is AWS.

By the time AWS takes notice of your product, you should already be quite successful at your own business, in a way that they can't compete. The companies AWS stole lunch from didn't do this properly, and their only recourse was a license change.

> a power you say they shoudn't abuse - and most of the examples I named did

Yes, I'm not arguing those companies don't exist. I'm saying that it's not in their best interest to do so, considering how much community backlash can hurt them. You also ignored my two examples of companies which I think do this right, and have successful businesses.

> Also, Wordpress has a lot of competitors.

Sure it does. Hooray for open source. https://wordpress.com/hosting/ lists some of them. The goal for the original authors is to offer the _best_ service so that customers will want to choose them over the competition. Or maybe they can focus on a certain slice of the market, and leave others to cover the rest. The pie can be big enough for everyone. This is not unlike any other company. Competition will always exist. But again, the original authors will always have an advantage. Not knowing how to do this properly speaks more about the company than about open source. This isn't impossible, just very difficult.

So a bit of the right words to the matching user base and with good points. Just that you always need to draw your own conclusion from your unique position.

Kudos for the the nicely adapted Jurassic Park scene.

We have a lot of client libraries, already open sourced. Then we have the hosted APIs and DB which are not open. Making all the close-source stuff open, feels like a big effort, with an unclear reward and more likely that we just end up with a hard to install OS project, since it feels like the hosting expertise _is_ part of the core value prop.

What I'm excited about though is whether we could take the hosted piece out of the equation and find something that is pretty different, but has its own niche. For us this would be replacing the web UI and DB hosting of the paid product, with a CLI and simpler git based hosting for an open source version.

ie If you want hosted feature flags, we think you should use the hosted thing, but if you want gitops style feature flags (100% reliable), then use the OS version.

I like the idea that we could really focus on making the open version great in its niche, but have a super clear line about what is paid / hosted, to help us avoid the complexity of always needing to decide how to nerf the OS version.

> Secondly, and more constructively, you should prepare for this eventuality by finding areas where you can outcompete anyone. Most cloud providers are notoriously bad at Developer Experience for example, so take advantage of that and make DX one of your core competencies. If after 6 years, Google tries to steal your lunch, you should have a brand, a team, and a community, that have spent the last few years preparing for a David versus Goliath-type fight. Make sure you're not blindsided by something like this by planning for it from the beginning. You have enough time and focus on your side to construct a winning strategy.

Consider Google Firebase, which runs on Google Cloud and can access services from Google Cloud[1], but has a separate frontend, focused on DX rather then features, and imagine Amazon Supabase.

[1]: https://firebase.google.com/firebase-and-gcp

However if you are not ripping off some popular commercial tool and making it open source, and making open source as your main differentiator, in that case there is very little to gain by going oss. You might as well get most of authors advertised "oss benefits" by just having great developer experience and docs, while giving very little in return.

If your answer is the latter, then you have more problems in store than open-source viability. You aren't genuinely testing/dogfooding your product. Your product goals will trend away from real customer value and toward implementation convenience, self-compatibility, 3rd-party incompatibility, and a closed-minded product vision. The only way to keep this business model viable is to monopolize your market. But will it be you monopolizing, or will it be FAANG?

I get that legally this is fine but ... Common... adapting FOSS for your own use cases in your basement or little company is still very different then a giant cooperation outcompeting you before you ever had a change...

There might be room for a license to make FOSS software more like BSL if used by a company above a certain revenue threshold or w/e... Perhaps legally that's impossible, otherwise I have no idea why such a template does not exist yet.

- they like the idea of "security through obscurity". Open source means more work patching found vulnerabilities, so they rather not publish their code and instead tick check-lists for compliance and do blackbox pentests which makes them look secure.

- like to do marketing that exaggerates the innovation of their product. That's difficult to do if everyone can see the code.

Without starting a flame war there are good and bad reasons to choose an implementation language and they should be driven by your business needs, whatever they are.

The same is true for how you plan to license your code and what business model you build around it.

I'm thinking: I will give it a closed source grace period, then, by that time, it should either be:

1. A dud, so close the offering, show the source.

2. Working well, in which I can open-source and rely on brand recognition to carry forward the business.

Releasing as AGPL3 at least means that I get some code contribution back, (right? Right?!)

Free software is a gift from anonymous folks. A gift from a friend can come with moral obligations - depending on your cultural background.

Open Source is a licensing and development model.

With traits of a religion.

We’ve usually got some hardware and firmware closely bound together, with traditional model being selling hardware with proprietary firmware.

Any examples?

IoT has the problem that many devices but few users per device. So who is going to make the effect to build an integration for third-party software? The FlowFuse model is to allow the community to do that while they (indirectly) upsell that work.

FlowFuse also provides the SaaS solution for commerical gains.

[0] https://flowfuse.com/ [1] https://nodered.org

Still what they released as open source stays open source, so it's still a win. Also if contributors don't sign a CLA, then it makes it harder for the company to go proprietary. To me that's the only thing: contributors should not sign a CLA: either contributors keep their copyright, or they should not contribute for free.

Even if for profit and all

You have inadvertently chosen a perfect example of why free software is better than proprietary software.

https://en.wikipedia.org/wiki/Coca-Cola_formula

The specifics of the Teller-Ulam design is one of the best kept secrets of all time. It’s impossible to keep secret the list of ingredients in a thing you literally provide for sale to any member of the general public.

Don’t eat the pasta.

You're also correct on the second bit, everything in the stack is MIT, apache2, postgres licensed so it would have been ok to run a closed fork if we'd have been that way inclined.