On Mon, Jul 19, 2021 at 10:33 AM Pierre <pierre-...@processus.org> wrote:
> Le 19/07/2021 à 10:11, Lynn a écrit : > > A vast majority of proprietary code depends on open-source community > > written by the community. > > All your arguments are good ones, even if in my position I don't agree > with everything. Nevertheless, I specifically don't agree with this one: > a lot of proprietary code _uses_ open-source community code, but is not > always tied to it. You're ignoring all projects that took the other > direction, clean architecture, business libraries, dependency-free code, > and others, whose goals are not to be dependent upon third party, but > rather integrate with them in the software stack edges, making it both > replaceable and discrete. I don't write "Symfony" projects, I write > business domain projects, Symfony only brings a nice dependency > injection container and a router I could both replace easily. > Hence I wrote "A vast majority". Even if it's not your code directly, your application has a dependency on open-source php software that is often directly impacted by every decision voted on for php, whether this is Symfony, Pimple, Laravel or any other dependency injection you've decided to integrate. If you choose to use abstractions, then I think it's only fair to have the authors of those abstractions have a say in changes that impact their abstractions, whether it directly impacts the "end developer" or not. > In my use case, focusing on my code is what primarily matters, and I'm > not denying language changes are impacting for open source software, but > I trust PHP for always keeping its BC promise (and it does, probably > thanks to "In fact, open-source package maintainers are often one of the > first lines when it comes to PHP compatibility"), which at least resolve > that. > I fully agree with this, as a developer I do not want to worry about low level php changes that do not directly impact me. Therefore I think that people who do get impacted by this (for example open-source package managers), at least get a vote in these changes. It's unfair to put the burden of writing abstractions on someone and then tell them they don't get a say in making their lives easier or more difficult. --- Other than that, polling with the community to see if an idea can get traction before more proposing it on the mailing list or through an RFC is always a good idea in my opinion.
