@heiglandreas I might be missing something here, but these two are not in the same problem field, are they?
Symfony has a PropertyInfo component for years, which uses PHPstan and phpDocumentor's type packages (the one you're linking here!) to resolve property types. This component used to have a single Type DTO class representing all type information.
@jaapio@heiglandreas yes, I saw it later this morning.
Let's keep talking and see where our needs overlap and we can work together, just like on the rst parser.
@jaapio@heiglandreas I just always get very triggered by people mentioning NIH in Symfony.
For me, it feels like we get accused of having a secret plan to get all PHP packages to start with "symfony/" in some years.
From working in this group, I know this is not the case and we're all just eager to write code and publish features (+ save ourselves maintenance time). Most of our discussions happen in the open on GitHub and we have no secret bad intentions to any individual on this world.
@jaapio@heiglandreas I realize this sometimes isn't the feeling that we get across.
Async communication, and textual async communication in particular, looses a lot of emotion and can result in bad feelings for people reading them.
Please reach out to us if this is the case, like you did. We'll learn from it, be better at communication in the future, and create new contacts with the PHP community for the better of everyone.
@wouterj I know that the symfony team has the best of intentions and I had great chats with a few of them also about that topic. Still IMO what comes across often is NIH approach. Especially with people not that deep into the community - which is kinda most users...
And while I can and do understand the reasonings behind the approach I still believe that there might be other ways.
And if it is only to very early get in contact with maintainers of external packages...
@heiglandreas@wouterj@jaapio I know what a number of the concerns are that prompt things like this. That said, having been an author of several components where this happened, I can also say that it's hugely dispiriting when your work is essentially forked and modified only slightly, just so it can comply with the Symfony release lifecycle or its preferred API. You end up losing users and contributors, and any fixes or improvements on the symfony version never make it back to the original. 😐
@mwop in this can it wasn't an adoptation but just a new build project. However when I read the code it's very likely that the authors had a look at my project. Class names are equal, and also the structure of the code looks much like the original project.
I would have been open to help them out, which I did before. If I just got a question. It's not that phpDocumentor is a new project. And with more that 7M downloads a month it's not that you can not trust it.
@heiglandreas I agree, let's become more converging as a PHP community and ping authors of relevant packages in the community reviews (if we know them ofc).
That said, I think this also applies to how we deal with it afterwards. Messages like your first post often result in a more diverging community. Let's try to understand, from both sides, and not shoot one-liners. People reading the message don't know about those "great chats" and will only remember Symfony being the bad guy.
I had huge arguments when I worked at SL with one of the future core Symfony contributor (mainly UX) because he had (IMO) a very selfish vision of FOSS, and he deliberately, without ANY discussion with the big-players, created packages to "replace" what he thought were "old and dirty" packages. He did that at least 3 times in his Symfony contributions, I was pissed because he NEVER contacted ANYONE for that
And yet, since he made sure to become super friends with one of the main Symfony core members, he made sure to have the approval of anyone. It was only about using politics-like maneuvers into putting his name in the Symfony ecosystem. To me, again, very selfish.
Still, he did his trick, and some stuff is now built in Symfony and made sure external packages that were the main source for these usages just got lost, their contributions forgotten, for one guy.
@heiglandreas@wouterj@jaapio
I know Symfony , just like any FOSS project, has to have a governance system. However, I feel like it's more "Everyone is welcome, even if you copy the work of others and put it into Syfmony" on the outside, and on the inside, especially the leaders of the governance, it's more like "If we like you and you have the same opinion we have, and you're okay with doing whatever we say, we welcome you".
(been there, done that)
That's IMO the origin of this "NIH" thing
@heiglandreas@wouterj@jaapio
We got that for UUID (everyone was using either @ramsey 's lib or the extension) then for Html sanitizing (everyone was using HTML Purifier), we even had that for Workflow earlier (because everyone was using winzou/state-machine). It even happened when league/flysystem-bundle was created with ZERO discussion with the creators of oneup/flysystem-bundle who did an awesome job to integrate flysystem.
Each component brought a tiny bit of new features, then hype rose because "it's brand new" (spoiler: it's not. I call this the "Apple effect"), and contributions came.
That's not my vision of open source.
That's the capitalist vision of the MIT-based open source.
@wouterj@heiglandreas@jaapio crazy idea, but why does Symfony not publish about plans for new components, and invite the wider community to collaborate? Instead right now, the new components are announced when they are done and it is a surprise to "competing" component maintainers. This results in comments about Symfony's NIH syndrome that, while perhaps not the best way to communicate this, I can honestly understand. That is by now my default response as well when I see something like this.
@Skoop Or perhaps, instead of maintain a new version of an already established project, create a slim wrapper around the existing lib that can make sure that all the specific needs for Symfony are met.
Less maintenance-burden and perhaps even time to contribute to the existing lib
@Skoop the reality is that there is very little plan. If we say we don't have a roadmap, we mean it :)
For those announced at conferences, the component is just as much as a surprise for you as it is for the core team (I'm also totally not sure if that's a good thing!)
For all other components, the first time we hear about it is when the PR with a draft idea is opened. This applies to components created by core team members, and by ones created by community members.
@Skoop@heiglandreas@jaapio to illustrate and be totally open about this: at the moment we have a couple components that we consider for future Symfony versions on GitHub. All of them are initiated outside of the core team (just like TypeInfo was) and currently in review, test and mature phase:
@wouterj As "symfony" brand owner I would now be alarmed.
As that means that anyone can create a draft that is nothing else than a fork of some other popular project and trigger the same discussion and symfony will get the blame why they are copying a popular package...
@wouterj@heiglandreas@jaapio so perhaps we should implement a new flow. One where collaboration and communication is more central. To promote reuse and interoperability for libraries and frameworks.
Perhaps we should create a group, let's call is the Library Interoperability Group, LIG for short, where these things can be discussed.
Add comment