For a very long lived PHP web application project, is custom (self made) framework better than (open source) popular frameworks?

Question

For a project that's going to live/used/maintained by the developer for a very long time (ex: 20-50 year); Is custom (self made) framework better than (open source) popular frameworks? Basically my highest priority requirement is security and very long term lifetime.

My current situation is having to maintain 15 year-ish old web application written in PHP5 (at the time, it was a cutting edge application since PHP5 released at July 2004. The application used custom, closed-source framework (since I imagine at that time there's yet any popular or mature frameworks yet)

The application have served the organization for long time, and it's rather business critical. I'm trying to make a new mobile friendly version of it (to run alongside the old one). Should I use the same framework, or should I use newer frameworks like symfony or laravel?

[A] When I read the source code of the old framework, I realized that there's a lot of demerit:

• a lot of it didn't follow some of OWASP best practices (I can't say which ones);
• no automated test, no documentation (every time we need to change something, we're reverse engineering it and hope things didn't break);
• a lot of bad PHP programming practice in general (variable name upper\lower-casing, drowning in warnings, gigantic monolith, no null safety, very loosely typed, no error logging, not using abstraction layer, basically going against every PSR that exist out there)
• basically a very huge technical debt

[B] Even so, the consideration of keep using our old, custom, closed-source framework is that:

• it's more secure
  • security through obscurity (only us know the source code, unlike open source frameworks which their code are basically 'leaked' through the internet),
  • AND security through very strict network firewall rules,
  • AND security through enforced legal and organizational law);
• more understandable by the team (us);
• PHP5 will still run on servers;
• it's lifetime is forever (since the team: us; still maintain it and patch security vulnerabilities), - it will never get deprecated, never get breaking changes; I know that symfony provide LTS release that receive maintenance for 4 years. But it's still very-very short in term of the application's lifetime (our team expect 20-50 year);
• it's receiving very huge amount of request every day, no framework (less footprint/resource usage); even if I try to change to new framework and follow every best practice out there, it'll be bad practices again after 20-50 year
• our requirements doesn't mind if the app appears old (in html/css presentation); that's not where our customer find us

My question is:

• should I propose for a change of framework and design?
• is there any of my point in [A] or [B] that is wrong or misguided?

Related question (but quite different): https://stackoverflow.com/questions/1836351/thoughts-on-abandoning-proprietary-framework-for-a-larger-open-source-project (my question is more on security and long lifecycle)

Answer 1

There is a lot to unpack here. Let's start with...

1. Security through obscurity

Obscurity in and of itself does not provide additional security, unless it is so utterly complete and total, that it barely balances being usable.

Are your company records secret?

Are you sure an attacker can't find out who used to work for your devteam?

Are you sure none of ex- or current employees have any copies of the source code on their home machines?

Are you sure that they maintain secrecy and will not spill the beans willingly upon social engineering attempt?

Is your server running an OS that has no vulnerabilities?

Are you absolutely sure an attacker can't get access directly to the server physically?

Is your team really THAT good and all the points of contact (which are exposed and therefore not obscured at all) in your framework are secure?

If you can't answer a strong "YES" to every one of those questions (and many others), than obscurity is not going to help much.

Which brings us to...

2. More open means more secure

It is just a simple numbers game. There is a set percentage of security specialists amongst the population of developers in the world. If more people have access to your code—higher number of professionals will check it out and spot the problem.

This has been the working solution for pretty much every collaborative project in the past couple hundred years. That is how Wikipedia operates. And it is how most modern frameworks operate. They are open sourced in part due to security concerns. It allows them to prove that they are not hiding anything, and in turn, security professionals from all around the world have an opportunity to contribute their experience and skills to the creation of these frameworks.

The dedicated security solutions implemented in open source frameworks will beat you in terms of security. That is, unless you are absolutely sure that your team is able to achieve a world-class security in your custom-tailored closed-source project. Which brings me to...

3. Longevity of code

You have to rememember, that your framework is not floating through the void of space. Your code interacts with a lot of other systems.

You say that you use PHP5. It is now firmly in its "end of life" stage and will never be updated again. Are you comfortable using a system that has a bunch of well-known and widely publicized vulnerabilities? No matter how good your code is, and how strongly you obscure your system, those are not going anywhere.

When you say that PHP5 will still run on servers, do you imply that it will just work indefinitily? Because it most surely won't. As the years go by, support for it will be dropped by major webservers, because there is no reason to drag all of this old, vulnerable, and barely used code along.

So unless you are going to keep your entire architecture the same for the next 50 years, your application is going to stop working as expected at some point. And if you do, then expect to have a lot more vulnerabilities to worry about.

4. Nothing lasts forever

Here is a list of things that did not exist 30 years ago: https, http cookies, JavaScript, PHP.

It is difficult to tell what the web will be like in 5–10, let alone 50 years. Requirements will change. Your application will have to adapt. If your team can pull off writing an web application that will live for so long, using a closed-source framework, based on technologies that are already dying—hats off to you.

Answer 2

In general, yes, its probably better to have your own targeted, purpose-built framework in place for such a long term project. I say this as someone who manages a few 20+ year old PHP applications. You would not have wanted to be stuck with something like PHP-Nuke for 20 years. Frameworks are convenient, but you have to go into them understanding that you're placing a great amount of trust in their future viability. And if they make too major a change to the framework, one that requires too much re-wiring effort on your part to upgrade, that can leave you stuck 'locked' into an old, insecure version.

To your larger point, you seem to be proposing an all or nothing type of replacement, when such a choice isn't necessary. Your application isn't written in PHP 5. It's written in PHP. PHP is still around, and the latest versions can run code intended for PHP 5 often with little or no changes. So your better approach may be to adjust the code to run well with the latest maintained versions of PHP 7.