Hacker News Reader

Comment by 0xbadcafebee | Hacker News Reader

Does anyone genuinely make their choices for what product to use based on if its source is available?

I don't want to read the source code, I want to use the product. If there is a bug, I want you to fix it. If you don't fix it, why am I paying you / using it? Assuming I am a programmer (many users aren't) and make my own patch, and you don't merge it, I'm still screwed. Source only helps me if I'm the one running the code. So the fact that your SaaS is source available has no bearing on my use of it.

View on HN

Lots of businesses have agreements with vendors to keep the source code in escrow, in order for the business to be able to ensure continuity if the vendor goes out of business or abandons the product.

How does that work exactly? They have rights to get a 3rd party to maintain the product if the original vendor goes out of business?

They can either maintain it themselves, or let another party do it for them, indeed. The contracts specify under which circumstances the code can be released, but usually it's going out of business or cancelling a product.

It's something we had to deal with in a previous job where we (as a small company) sold products to Global 500 companies. Either we agreed to this, or there would be no deal. Every time we released a new version to those clients, we would place the updated source code (along with documentation and tooling etc) in escrow.

Ty for the info.

What exactly is escrow for source code? Some party you paid to upload a tar.gz to an sftp server?

When I've done it in the past, it was a vaguely tech-savvy law firm (the hard part isn't really the storage, it's the "evaluate the conditions of the escrow contract release terms".) (IIRC recommended by the customer but we had some independent validation - I think one of our VC's law firms had dealt with them before?)

We also had to details on how to actually build the product from the source, though I think they mostly just trusted us on that as long as we supplied a separate document - and by trusted, there were penalties spelled out in the contract about that too. (We were in good shape releng-wise but I expect a lot of companies would have to clean up their act to actually comply with that part.)

Those release terms are interesting to think about. I’m wondering how to spell out in a contract the difference between selling your company to a firm which will maintain the software well vs selling it to someone who will ruin it and/or do the most bare minimum? How can one draw the line?

Escrow in general refers to a third party acting as an intermediary trusted by both parties. This works for source code, but also for money, goods, or anything else. Say if I want to buy a large diamond from you, you hand it over to the trusted escrow service, I give them a big pile of money. Once they have the money, they give me the diamond, and then give you the money.

Only in the case of source code, I give them the code, and they won't give it to you until I go out of business. They get paid for that, of course. In our case, we uploaded source code an escrow service's servers.

This is one of the reasons I personally went fair source/source-available. I was already sharing my code with my biggest customers via escrow, so I thought I'd just simplify and share with everybody and give everyone the same benefits i.r.t. continuity and longevity.

This software ensure this happens as well.

> We hereby irrevocably grant you an additional license to use the Software under the Apache License, Version 2.0 that is effective on the second anniversary of the date we make the Software available.

[1] https://github.com/billabear/billabear?tab=License-1-ov-file

Of course some people do! Programmers mostly, I would expect, since they can possibly patch or audit code which may be a requirement.

Personally, I would never reach for a tool or component or any piece of software if I have to run or operate it unless I can change the code.

Now, "source available" has another implication, however...

Source available can be helpful if you want a local dev setup or testing environment.

>Source only helps me if I'm the one running the code

Many times I've gotten better support when I open a Github issue and send the link to support--usually I can get around all the canned troubleshooting steps and get to an engineer quicker.

>So the fact that your SaaS is source available has no bearing on my use of it

You can tell if the product is garbage before you pay for it (does this place review changes, do they have automated tests??)

imo it's still helpful although small. If you're looking to run it yourself, sometimes source available can quickly be ruled out--especially if your company reviews and tracks license terms and doesn't want the headache of something custom/complicated

If you're a large commercial software house, with $$$$$ of revenue riding on things working/being able to develop features quickly the usual "contact support, tell them about issue, wait for fix" flow can cost you a lot of time and money.

Even large businesses that don't produce software as a product often have internal dev teams that customize third party software to their needs (at least in the particular vertical that I'm involved in).

It's immaterial in these cases whether the code is properly open source or not, but being able to go in yourself and fix minor bugs that are blocking you in hours/days rather than the weeks/months it might take the vendor to get back with a fix is practically a hard requirement for any dependencies that are core to your business.

Yes. I avoid closed source software whenever it is practical to do so.

I'm not an OSS zealot but when there are many options available all of similar quality, or I don't care about advanced features, I almost always pick the OSS alternative. e.g. music players, pdf readers, note taking software, etc.

In this case since it's more of a SaaS I don't know if I would make that choice, I'm not familiar with billing software however not being 3rd party dependent and knowing you could self-host later if needed sounds useful.

I think a big value prop is that it reduces vendor lock-in, especially when depending on a new company. If the company fails, you can self-host and even fork. You can also choose to self-host for compliance reasons if your sector doesn't jive well with multi-tenant SaaS.

It's not strictly a SaaS if the license allows you to host it yourself at no cost.

Yeah. Part of why I picked Kong at a previous job was that it was modifiable and open-source, and the enterprise plugins were modifiable and source-available. It allowed us to deploy custom versions of them for our own use-case.

Reply on news.ycombinator.com