Et ça va pas bien chez eux…
2 « J'aime »
Là, ça dit plutôt du bien de WP, mais c’est surtout intéressant pour l’analyse et les nouvelles de Drupal :
A croire ce Mullenweg c’est un type plein de bonnes intentions qui a trouvé un méthode qui marche, son projet open source bat tous les records et échappe pourtant au sort de Drupal.
I would like future generations to grow up with a web that is more open, more free, gives more liberty, and so open source is really my life’s work, even above WordPress and anything else. I hope to work on it the rest of my life.
C’est une bonne chose de regarder de temps en temps comment font les autres, car la question se pose aussi pour SPIP, pour son code, ses utilisateurs, ses contributrices et contributeur et les entités économiques qui existent en relation avec notre projet: Comment défendre la liberté dont nous jouissons en travaillant pour et avec SPIP, comment maintenir et améliorer ses qualités et surtout comment donner de la vie la communauté SPIP.
Je suis assez content du fait que le système SPIP ne soit pas produit dans un esprit libéral états-unien même si beaucoup de ses points positifs font partie de « SPIP » au sens plus large.
SPIP est différent. Alors est-ce que c’est utile de se poser les questions qui sont urgentes au sein du domaine états-unien?
Je ne le pense pas. J’aimerais agir avec SPIP comme noyau pour la création de bandes d’amis et d’amies alors que tout le monde parle de « compétences », « features » et marchés. Les capacités techniques du système SPIP sont l’outil qui me sert à cette fin. Si j’y réussis cela se fera à cause de votre soutien, du style du code, de l’architecture et de l’idée d’anti-propriété collective à l’origine de cet enfant au nombreux mères et pères qui a atteint l’age adulte il y a trois (ou cinq) ans déjà.
Voilà, c’est pour dire merci à vous toutes et tous.
Continuons à nous poser de questions 
:-)k++
1 « J'aime »
L’avis de gu://au.me sur Mastodon
La plaie dans cette histoire, c’est que Mullenweg avait trois bonnes intuitions pour le futur de WordPress, avant de risquer de couler le produit.
- Le nouvel éditeur (« Gutenberg »).
- L’édition collaborative.
- ActivityPub.
I often think back to my days with Drupal and the horrible development choices they have made. I used it at version 6, back in 2010, and it was presented as a dynamic and configurable Wordpress alternative that goes beyond blogs and is built for customization with a solid core.
Then version 7 came out, and nothing that previously worked was working on the new version, paradigms shifted to more object orientation and developers were asked to re-develop their plugins to make them work on a new core. They also adopted composer as a way to install the system. They brought in a templating language Twig from another project.
Then 8 came out, and they completely re-re-wrote the core, but somehow the codebase increased from a few megabytes to like 80MB of code. It turns out they picked the ORM from Symphony, other things from Yii, and a myriad of composer dependencies were added to the project.
Of course this completely broke again everything that was ever developed for the platform.
This is when I had to turn my back, because I didn’t want to be responsible for hundreds of composer dependencies, all on their own release cycle, with their own security updates, and a system which was at the « core » actually Symphony, Yii and others. Nothing of what made Drupal interesting was left, and when you had to debug something, you ended up going through code that loaded more code, that brought in another framework, that actually did something, but then how do you fix something 3 abstractions down in a code when it is just « a simple dependency » of the project? I mean how do you actually add code to the project so it is not overwritten with an update, and how do you keep track of integration of your code after upgrades? You’d need a team for just that.
@JLuc you point out that Drupal was acquired and received investments and I believe somewhere along the way Drupal went from a one-person CMS to a corporate CMS, and this was their downfall. Instead of building on what they had, adding and internalizing more to their core, making smart choices that last, they went with the hottest ideas in the market, and tried to make the « best product » at every version, jumping on OOP or composer or this or that ORM at each version. They also wanted to appeal to large corporations, who have teams and meetings to discuss adding a CSS file to the project.
In the process, all small teams had to abandon their Drupal project, or raise themselves investments to grow with it. It’s horrible and I don’t think there is any awareness of how much damage this project has done to their community. All the people who built projects where they could not charge their clients for « upgrades » - they ended up failed projects.
When you change vision from a one-person system to a corporate system, you need a team to handle it, and in the corporate setting that’s not an issue (it is, but it doesn’t seem to be). One person just to keep on top of security releases of all the 100s of dependencies. 1 person to manage the « assets » of the project. And of course extremely talented developers to handle the impressive complexity.
And this is why today, to add a CSS file to Drupal, you have to define a YAML file, and write a PHP function. And write the CSS file, of course. I am not kidding. See here: https://www.drupal.org/docs/develop/creating-modules/adding-assets-css-js-to-a-drupal-module-via-librariesyml This is a great example how how you can utilize a large team and distribute the workload among multiple people with clear responsibility. It also divides productivity by the number of people involved, but that does not seem to matter.
Productivity does not seem to matter for Drupal, but it matters to me. That’s why I was impressed when I was able to use SPIP squelettes/templates from SPIP 2 on a SPIP 3 site without issue. And when I upgraded from SPIP 3 to SPIP 4 and the custom plugins just kept on working. And the way SPIP handles security issues, I’ve pointed out before, is brilliant and many open source projects could take note of that.
I see that SPIP is also incorporating more dependencies via composer, and I have mixed feelings about it. I like composer, but I also think it’s important for SPIP to remain SPIP, to remain an independent system that can be used by solo developers and small teams in a productive way. A system where you can write code and don’t have to worry that each future release will break it. And this has been the case so far and I think it’s a real strength of SPIP.
Sorry, my rant about Drupal has been cooking for a long time.
Cheers,
Urs
4 « J'aime »
@2a08d92699ec237569fa thanks for sharing your experience on Drupal ecoystem!
However « composer » is not a specific content, it’s just a developer tool (and not a mainstream tool) to grap the right version of a PHP module/library (and its dependencies). And… now 99% of PHP pieces of code is grabbed by Composer, because it is THE main and central way to be sure to download the right version of this or that.
And as the SPIP team is not so large, and doesn’t want to re-invent the wheel or maintain complex pieces unnecessarily, it’s logical to add dependencies to external libraries. For ex to send emails, to log errors, or any other things extremly well maintained by other teams in specific libraries.
Normally, you, as a websites creator/maintainer, you never have « to be responsible of hundreds of dependencies » : the only ones who are, are the maintainers of the software core you are using. Because if there is a new security issue or major issue inside a dependency, the core team will update the JSON, and will release a minor corrective version of the software, no ? So you just have to follow the releases of the software you are using.
In future versions, as you already noticed, SPIP will use more and more external PHP libs, in order to maintain only the specificity of SPIP. But we have to be careful that it must always be simple to install, and simple to extend (especially for frontend integrators).
1 « J'aime »
As long as you don’t swap out modifier_object with Symphony’s Doctrine and abandon BOULCEs in favor of Twig, I’ll be a happy composer user. 
I think there’s a trend of using micro-libraries. Pulling in a dependency when it is literally 5 or 20 lines of code. In my opinion, it’s better to copy over the code than to bring in a dependency. I think this over dependency culture should be avoided (example leftpad: npm left-pad incident - Wikipedia).
Luckily SPIP hasn’t followed this trend.
We have no plan for using Doctrine in the future, at least, as long as I’m around
And we try to be careful in adding third party packages: library volume, maintenance status, some popularity, …
1 « J'aime »