Missatge de Deleu <deleu...@gmail.com> del dia dt., 27 d’ag. 2024 a les 13:55: > > > > On Tue, Aug 27, 2024 at 2:06 AM Andreas Heigl <andr...@heigl.org> wrote: >> >> >> I see this a bid differently to be honest. While I understand that using >> third party packages in our internal tools might make things easier in >> the short term it will cause a lot or additional work in the long term. >> >> Currently we have a lot of small scripts that do one thing. And they do >> it for a long time with very little maintenance effort. Blowing these >> scripts up with third-party libraries will mean that we will have to put >> in much more maintenance effort for either keeping the dependencies up >> to date or mostly rewriting the script the moment a change needs to >> happen as the libraries will be outdated. >> >> There are though some actual console applications like Pdt where it >> might be valid to use third party dependencies. But also here I'd ask >> whether the maintainability will be increased. A totally different >> question though is whether we actually need to maintain a special tool >> for building the docs or whether we can use a pre-existing tool for >> that. I am mainly thinking about either phpDocumentor or a default >> docbook renderer. But that is a totally differnt topic IMO. >> >> So I'd see this exactly the other way around: >> >> usage for infra needs very careful consideration to not increase the >> maintenance-burden on those that actually 'do' the maintenance. > > > I like the fact this has been brought up as it seems an equally important > consideration from my perspective. On one hand I remember reading about how > PHP Internals could hugely benefit from more volunteers to help maintain the > auxiliary projects of the language - which doesn't require C knowledge. > Perhaps this 'need' might be outdated now with the Foundation hiring > employees to work on PHP. On the other hand there's this really good point > about not creating a burden for existing maintainers of existing tools. > Ultimately, I find it important to consider that a tool that has been "mostly > no maintenance cost" for 10~20 years, then it might be following PHP > development practices so long gone that it's harder to capture new > volunteers. I understand there's a historical context in the 2000's where PHP > frameworks would come and go and most companies had their own in-house > framework. That reality is long-gone and community projects like Symfony, > Laravel and Composer are sustainable businesses that simultaneously rely on > PHP and make PHP better. Nowadays it is unlikely that a PHP developer will > pick up greenfield work with the language without using some reliable tool > provided by the community. > > As it has been said, it is a disservice to the PHP project to be stuck on > vanilla PHP for things that require improvements, maintainers, revamp, etc. >
It would be helpful if you could share examples of open-source, long-term websites built using frameworks like Laravel, Symfony, Laminas, CakePHP, or similar, especially those to which you have contributed, ideally maintained by volunteers. -- Pere Orga
