Since they have a /pricing page it would seem their business is not to make it easy to self-host but in fact to make people pay for the cloud version instead.
The best way to test this hypothesis would be to send a pull request that makes the self-hosting docs clearer. If they accept it then their business does not rely on self-hosting being hard.
That's not a sufficient test, because when put under the gun there's no reason not to believe that a company playing those kinds of games won't take that pull request, temporarily improving the situation, and then simply make no effort to keep it up to date later. Addresses the temporary embarrassment, but not the underlying problem.
Mind, I don't think Plane's one of these. The open-source release seems comprehensive and the doc just seems not very good because the people who wrote it are experienced operators. But the claim being made isn't one that's easily put to rest except through the company in question committing to enthusiastic and comprehensive support that dispels doubts. (And, well--they chose that life!)
That's a sufficient test. It's the community's prerogative to keep it up to date later with further PRs. I don't expect anyone, whether a company or a volunteer, to do ongoing maintenance work on features that don't directly serve them. The thing I'm testing for is whether they'd block someone else contributing a change that doesn't serve that company or volunteer.
Yeah, my experience with working at a startup that did fairly explicitly rely on self-hosting being hard enough that people would pay us instead was that we definitely never had to go out of our way to make that be the case. Making self-hosting easy is a significant amount of continuously ongoing work and we simply underinvested in that. If someone did all that work for us one time we would have happily accepted it.
Why are people so hostile towards BSL? Paying/asking money for great products is fine and if the product's source code is in git, the better.
Not everything has to be _free_. The major benefit of OSS for many is that you can read the source code. The major benefit of paid SaaS is that things just work and you pay for that. BSL can be the perfect combination of these.
I can't speak for other people. I'm not hostile to the BSL, if a company wants to license their products under BSL, I don't care, I will just not use it.
The main issue I have with the BSL is opensource-washing were companies basically release an open source product which become popular because it is open source, and then do a bait-and-switch and relicense it under the BSL restrictive license, but still claim "it is open source" which is a lie.
They're not hostile to the BSL. Other projects that started out under the BSL (e.g. Cockroach) don't draw the ire.
The anger is at a company that trades on the benefits of open source, and then shuts that down when it becomes inconvenient. People think they're free-loading on the contributions of others.
Oh my sweet summer children. Feels like the author has perhaps never worked on a complex, big product or with any capable engineering management.
The worst and biggest messes in software engineering that I've seen have been situations where there was not enough engineering management. And those situations were fixed by... introducing proper engineering (and product!) management.
That being said, it is perhaps possible to survive with less engineering management in a situation where everyone is behaving and performing at senior or above level. However, realistically, that is very rarely the case.
Similar to the other top comment, you're saying everyone who believes this must be naive and/or immature. Except that's the opposite of my experience: the most capable, longest-tenured technical people are the ones who are generally most jaded about management. Myself included.
I believe that there are probably a lot of problems out there that can be fixed by "proper engineering management". The problem is that 95% of what's out there is improper engineering management, which makes everything even worse. The whole point is not that engineering management is completely unnecessary, it's that in actual reality it's a trumped-up support role with false authority and completely swamped with utter bullshit. It's not done properly; that's the whole point.
Sounds like a government intervention is needed and the monopoly should be broken down for a better functioning market.
However, I guess big tech companies have become part of the superpower games (USA vs. China etc.). Breaking up Google might just mean a Chinese company takes over. Can't trust the other governments to enforce similar market conditions.
So yeah, like you said, conditions of the universe :)
One point of view is that it’s a more efficient way for the tech giants to develop new features. An internal team trying to do greenfield work will inevitably be slowed down by bureaucracy, where a startup can iterate more quickly without all the friction of things like performance reviews, HR exercises, and if I’m being cynical, pesky issues like user data protection frameworks.
It’s risky, but the payoff for founders is significantly larger than what an equivalent employee would get for leading an internal project.
>...Sounds like a government intervention is needed and the monopoly should be broken down for a better functioning market.
You can break up the phone systems because the child companies can provide similar levels of service. But how do you break up a single search algorithm?
I’m curious, how does this project compare to slonik that is also a fast, lightweight, full featured, using SQL template literals etc ? Is there any reason to consider switching, for example?
Slonik also doesn't have the same lean straight forward developer experience as Postgres.js - again I'm biased saying that ;)
Postgres.js also does things that will make your queries perform better out of the box by implicitly creating prepared statements and using pipelining.
I suppose you could build Slonik on top of Postgres.js instead of pg as well, but that would probably only make sense if migrating to Postgres.js.
This one just made my day. Thanks. I remember trying to build a tool at work with as little as possible dependencies (in python) and how satisfying it was to see quite a few dependencies just being wrappers replaces with 5 lines of my own code that i could easily audit and ensure no supply chain attack was possible for that functionality.
I already have a way to unify my messaging across different apps. It's called MacOS and cmd+tab. Sometimes on the road I use something called iOS. Sure it's not the same. But is it that different either?
All messaging apps have their own native features, some have E2E encryption etc. Not sure if there's a common subset that is enjoyable enough to use that it's worth it.
That being said, I do wonder what will be the "Facebook Events" (invite all your friends to an event) equivalent in the future when everyone is in a closed garden chat platform instead of Facebook.
There is definitely a benefit to having a unified interface. The vast majority of the time I don't want to use each chat apps specific features, I just want to message people. And then sometimes I want to be distraction free and turn off notifications. This is much easier if everything is routed through one app.
I'm also on macOS but I've been using Texts[1] for a few months and it has been a great experience.
