I've been the sole developer for my company's website for over a decade now. It's gone through a bunch of evolutions throughout the years, but I've been sidetracked lately and have let things stagnate as far as maintenance goes. Now, I'm looking to do some upgrades for security purposes and I'm trying to wrap my head around everything.

Some facts:

• PHP 8.0.12
• MySQL 5.7
• Symfony 5.4
• Web server is currently Apache only because that's what I've always used. I'm open to nginx or other options.
• Running on a Google Cloud VPS with Ubuntu 20.04
• I also use Google Cloud Storage to host thousands of images

My first thought was to take baby steps and start by upgrading Symfony as much as possible. However, the next major version (6.0) requires PHP 8.0.2. Symfony 6.1 requires PHP 8.1. Symfony 7.2 (the current release) requires PHP 8.2. So, then it just makes sense to upgrade PHP to the latest version.

However, I am terrified of upgrading PHP in the current (outdated) Ubuntu environment. So I might as well upgrade the distro while I'm at it.

And then, MySQL 5.7 is no longer supported, so I might as well bring that up to date too (8.0, I believe).

There will be no baby steps. I'm gonna have to just upgrade everything all at once. Which then leads me to my next question: should I stick with the self-managed VPS, or is it time to look at something like Google App Engine or Fly.io that is a little bit more managed and "locked down" than what I'm doing right now? Should I look into just going with Docker instead?

Put another way, if I'm going to start from ~scratch, what's the modern best practice to host all of this, given that I'm going to have to upgrade a bunch of different things all at once? (Turns out the "baby step" of upgrading Symfony will actually have to come last since I need to hit these prerequisites first).

Please let me know if I've left anything out. PS, security is a pretty big concern for us because we manage user auth, so I'm all for anything the cloud providers can do to take some of that responsibility away from me.

It's happening: We're launching a community-maintained Tildes source code fork!

Link: https://gitlab.com/tildes-community/tildes-cf

@Bauke, as one of the top Tildes open source contributors, is on board as a co-maintainer, alongside myself. I hear @cfabbro is willing to help manage the issue tracker as well, continuing their long term efforts from the official repo.

Tildes' admin, @Deimos, has direct access to the repository as well. Although he is not expected to take an active role in maintaining this community fork, he will have visibility into everything going on with the fork.

Why?

Deimos has a lot going on outside of Tildes. We want to keep the Tildes codebase well maintained and remove some burden from him.

Back when he founded Tildes, Deimos was working as a fulltime unpaid volunteer on it, continuing that way for a few years. Not just code, but on everything administrative and financial; public relations, as in communicating officially inside the community and beyond; moderating the community; system administering the systems. Basically a ridiculous amount of effort for one person.

Now Tildes is a side project, and he has a day job, and there is not physically enough time for a (human, non-drug-reliant) owner to do all those things.

How will this new fork affect the Tildes website?

The hope is that Tildes can merge relevant changes back into the official upstream repository. If we implement things useful and desirable for Tildes, it should be possible to get those improvements onto the website.

Why not just add maintainers to the official repository?

There are some features that may be desirable for the community, but not relevant to Tildes itself. This includes things like a Docker development environment, which code contributors may find convenient, but are an extra maintenance burden on the official Tildes repo, as Tildes does not use Docker in any way (AFAIK).

Adding us to the official repository would also create a different dynamic, where there'd be an implicit endorsement by Deimos of all changes. This means the burden would essentially remain on the Tildes administrator to review, critique, and greenlight every single change. However, the entire point of this endeavor is that there isn't free bandwidth for that.

Also this fork opens up possibilities like making the code reusable for self-hosting entirely new websites based on the Tildes source code. While I don't personally have any specific plans regarding such, self-hosting has been a repeated request ever since Deimos open sourced Tildes years ago.

Is "Tildes Community Fork" good enough of a name?

Thanks for reading this far! The fork needs a name. It will live in the "Tildes Community" GitLab group at https://gitlab.com/tildes-community/.

For now I've simply called it "Tildes Community Fork" and put it at https://gitlab.com/tildes-community/tildes-cf.

Any better naming ideas? It's not too late to change.

Next steps: We'll start migrating GitLab issues over

I think we're ready to start copying any "low-hanging fruit" issues from the official issues to the new community fork issues. If you have an issue you think qualifies as such, especially if it was ever labeled as "Approved" in the past, please feel free to copy it to the new issue tracker. Please link back to the original too.

It's still a side project for us

Please keep in mind it's still a side project for us. Although we're excited to push the project forward, please keep expectations in check. We're doing this as volunteers. Please be polite and don't rush us!