Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



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.


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.


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.


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.

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.


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/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: