Okay it's open source but self-hosting it is not straightforward.
The repo's self-hosting doc link returns a 404. Then after manually finding https://docs.plane.so/self-hosting/self-hosting, I am warned that there is a dizzying array of 4 env files.
I suppose they are in a tricky situation, in that while they want to stand out as open source, actually having people easily self-host it, is perhaps, not a goal that is currently in their interest!
Correction: removed wrong Docker-Compose command interpretation, as I have been schooled!
Spent 10 minutes trying to get it running locally, couldn't.
They suddenly mention nginx in the self hosting docs - why?!
I don't understand open source projects that required you to fiddle around with scripts, environment files, reverse proxies etc to try the platform out! docker compose up should "just work" ™.
No, they’re pretty clear - see the quote in my previous comment - it’s absolutely clear about the usage of ports. And you should have courage to admit you were wrong when you were wrong.
To be fair, 'try the platform out' to me includes getting an understanding of dependencies and configuration. Docker is useful for a lot of things, but even if I want to use containerization in prod, I'd prefer to build my own containers rather than being dependent on someone else's runtime environment, so getting hands-on with the setup is important to me.
If the goal is just to test the application functionality, a demo site that's already set up and publicly accessible would be much easier than having to deploy a Docker container.
In terms of Nginx, using it to handle web server functionality, and especially encryption, while acting as a gateway into your containerized apps is a pretty bog-standard approach, and makes for good separation of concerns. I don't see much value in having that stuff implemented separately within each application and creating more config complexity for sysadmin work.
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.
If you just follow the documentation [1], it "just works". I just installed it on my machine, everything was up and running within 3-5 minutes.
They even wrote a setup script that saves you from the mind-boggling complexity of docker, giving you a simple menu where you only have to read the items and press a key. If you don't know which key to press, the readme [1] is very helpful. The only place where you will have to "fiddle" with the environment files is to change the default port from 80 to another. And if you're not ready for that, or not skilled enough to understand what that means and why you might need to do it - you're not ready for self-hosting and should take a step back and learn the basics of OS administration.
Oh, and they mention nginx because this software uses nginx inside a container. Hope that answers your question.
well some people like docker and some don't. If you are in the self-hosting realm, personally I think it is fair that the people doing it knows about DevOp or systemadmin, or else pay someone to host it for you.
I think the parent comment just wanted to say that since this project uses docker compose then it should be a lot simpler to get up and running. Actually running something in production would still require some degree of administration and monitoring based on your use case.
On their webpage it says that you can get started in 30 seconds with their hosted instance. Would be nice if it was as simple to get started with a locally hosted instance.
Of course it is fair. Why would we consider "fair" for an open source offering trying to entice new users?
I don't want a new project, I want to try self-hosting the software. If I am using it and liking it then certainly I would put time and effort into it. If it takes some time fiddling around with docker even to use, well, I have other projects to fiddle.
That goes for all self-hosted, but especially so for a project management tool. I'd be trialing it because I have projects I already need help managing. Adding one more is friction that would likely turn me away.
> If it takes some time fiddling around with docker even to use
Where did you get this from? You do not need to fiddle around with anything to have it working. The only thing that _probably_ requires "fiddling" is the nginx port - and you need to change it only if the default port is already in use. Is it really that difficult nowadays???
That’s certainly the incentive of a company who sells paid hosting.
I think it’s reasonable to provide as close to a one-line / one-action initial install, even for people who are experienced admins. (Those experienced folks can edit/tweak as they like, but having a basic “push this and something sensible happens” goes a long, long way to getting people to succeed in trying the product.)
I want to know what configs are needed to get things stood up. I actually don't dockerize things right away. I setup my nginx to forward to different machines in my network. When I settle on a home for things, I may (finally) get around to whipping up a Dockerfile.
Not everything needs to be enterprise whizbang out the gate.
Software installation, even for simple trials reminds me of this Stephen Hawking quote:
"Someone told me that each equation I included in the book would halve the sales. I therefore resolved not to have any equations at all. In the end, however, I did put in one equation, Einstein's famous equation, E = mc squared. I hope that this will not scare off half of my potential readers."
It just feels like that law can be adapted to: for every step and pre-requisite in your setup, you lose half your potential customers.
Of course, it's not precisely that, but it feels the same.
I, for one, am not afraid of manually building a stack to self-host an application. I'd prefer it over Docker in fact, because it makes everything exposed, and as an admin, I love to know what I'm tinkering with.
However, the docs should be good. No hidden layers, no skimped over steps, no "insert some magic here". It's your app, you know it by heart, but I'm just getting to know it.
If you do this as an established application or a developer which also sell your product as a SaaS, I assume that you're doing it in bad faith, and move on.
Building an app that scales to enterprise size is hard. Building an app that does so while also scaling down to single-team size is hard. Every feature you build two backends for is one more thing to go wrong. Writing a sqlite backend for your redis usage, your search, etc... it's not insane, and it's a sign of good Faith, but it's not something that should be expected, either.
It's been a long time since I fell for the marketing slogan about a product like this being open source. I wasted a lot of hours learning that lesson. If a company has a financial incentive for something to not work, it's not that hard to make sure it doesn't.
I haven't look at this particular project, but having to type the same information into multiple env files is unfortunately pretty unavoidable. Making a Docker / Django project instantiable via template and then runnable locally and deployable in production unfortunately involves 5+ different variable templating systems, which each require their variables to be declared in different files and formats.
