Hi folks,
On Tuesday, 3rd November we discussed the ‘composerification’ of Mautic further, but discussions spun out in several threads so I’m going to add them below for reference as they aren’t featured in the meeting notes.
Read the discussion in the team meeting notes here.
Other discussions here:
Thread 1
| Yosu Cadilla | As for the composer options, not something the average Mautic needs or is going to use, ever! |
| ekke | for others would be great, though! 
|
| Yosu Cadilla | Yes, I understand the practical benefits of better composer compatibility for both developers and sysadmins, but guess what, we are currently doing pretty well on the developer side, while we are failing terribly on the user side.If it was a simple, non-breaking improvement, by all means!!! |
| Yosu Cadilla | Turns out is is not and would require quite a lot of work. |
| ekke | so “end user features are more important”? No doubt about that! |
| Yosu Cadilla |
 :skin-tone-2: |
| Nico Grienauer (he/him) Drupal/Analytics/Styleguides | for bigger more profession projects it is currently an obstacle to not have composer. but yes. it should be not prio 1. |
| Nick Veenhof | I believe we can do both at the same time
|
| Yosu Cadilla | @Nico Grienauer (he/him) Drupal/Analytics/Styleguides What are the specific use cases where it becomes an obstacle? |
| Nico Grienauer (he/him) Drupal/Analytics/Styleguides | what I have in mind: at our company we have a build process and we do not “click buttons” on the frontend to make updates of a system. if something has changed in a docker compose etc, then our gitlab runner starts to build a new system and checks everything. after everything is fine, we have a stage to test the system. if the stage is fine, we can merge this into master and this can be deployed then to the live server. Option 1) on the live server only the fragments which have changes will be addded/changed to the live system: done. option 2) a skript will do a git pull on the live system which is changing the missing files: done.the verisoning etc is set in the composer file, so we are in control, when and what will be updated and developers can count on, that they have the same system locally to develop.there will be no database pulled from live etc for a developer setup. if a db is needed, we could pull a dsgvo ready db with anonymoused data.so no editor/marketer should have the ability to click the update button or install any plugins out of the blue.I we don’t have control over the system, we cant guarantee stuff and “cant” help customer with support. |
| Nick Veenhof | Fully agree with Nico |
| john | The users doesn’t have to know they are using Composer but they do need it. If we need a good marketplace and the extendability of Mautic is the main drawback of the whole project as I see it then Composer gives us 90% of features that the Marketplace needs. I’ve already built a basic UI on top of it. The only blocker to finish the marketplace is the directory structure of Mautic.To sum it up, if users want Marketplace and one button extension installations then they want Composer. |
| Red | Composer can help a lot for building and distributing plugins. It would be great to have a example plugin to demonstrate how to use it. I try to build a plugin but it take too much time to set it up. ( I’m new to Mautic plugin drvelopment). |
Thread 2
| Jordan Ryan (Facet Interactive) | (Thread 2) Composerification vs. Marketplace priority |
| Jordan Ryan (Facet Interactive) | Going off of @Yosu Cadilla’s comments here. I see the core of this issue as two fold: |
| Jordan Ryan (Facet Interactive) | Marketplace is required in order to centralize the visibility of Mautic plugins, customizations, and functionality. |
| Jordan Ryan (Facet Interactive) | 2. The design and maintenance of Mautic updates predicates the marketplace in that there is no easy way for developers, let alone marketers, to maintain their core updates along with plugin updates in a version controllable way. |
| Jordan Ryan (Facet Interactive) | 2.a. - I don’t think that enterprises (the kinds of customers that are essentially bank rolling the development of this community, can scale collaboration in Mautic without better tools / features — and they all want to do this with the security and stability of version controlled systems. |
| Jordan Ryan (Facet Interactive) | Solving the composerification problem of the marketplace is a separate issue than composerification of core, though, and I’m reminded of hacky solutions in Drupal 7 such as https://www.drupal.org/project/composer_manager which handled a separate set of composer.json and vendor files in the installation. |
| Jordan Ryan (Facet Interactive) | Would this not be a potential solution in the short term? It is ideal that the Mautic project is fully handled from core composerification… However in the Mautic 3.x short term a Mautic Plugin that enables management of additional plugins as a post-install step could be the path towards marketplace viability. |
| Yosu Cadilla | Marketplace is required in order to centralize the visibility of Mautic plugins, customizations, and functionality.How badly do we need centralized visibility of plugins? There are already several pages, both official and non-official listing all the plugins… |
| Yosu Cadilla | 2. The design and maintenance of Mautic updates predicates the marketplace in that there is no easy way for developers, let alone marketers, to maintain their core updates along with plugin updates in a version controllable way.Why is that? |
| Yosu Cadilla | 2.a. - I don’t think that enterprises (the kinds of customers that are essentially bank rolling the development of this community, can scale collaboration in Mautic without better tools / features — and they all want to do this with the security and stability of version controlled systems.All of them? or a very specific few? |
| Yosu Cadilla | Solving the composerification problem of the marketplace is a separate issue than composerification of core,Indeed (or at least it should). |
| Yosu Cadilla | No one doubts it is a good idea to do it, we just think there are other priorities…https://forum.mautic.org/c/ideas/14And not in that list, things like re-visiting all the major integrations with other MKTG platforms, some seem to be broken since the pre-Acquia days… |
| Nick Veenhof | Actually, if we start by reshuffling directories, and make keep composer optional (as it is today) we can already achieve a whole lot. I’ll see if I can make a PR that showcases this |
| john | @Yosu Cadilla as you represent an average user of Mautic you must admit that current way of installing plugins is not user friendly. And plugins updates are even harder. |
| Yosu Cadilla | Yes, I completely agree @john. However:a) It is daunting if you compare it with a tool like WP for example, but not compared with other tools more geared towards business, that tend to be more “corky”, because there is supposed to be some tech guy managing them.b) We got used to it, no one is complaining about it, or is it and I missed it?c) I believe the point is not whether it would be good to have this, the point is that given the very limited resources we have, we can’t do everything we want/need.If having a better way to install plugins means rewriting Mautic, then it is probably not worth the effort at this point in time.In my opinion, our scarce resources would be better used making Mautic more competitive/compelling on the business/marketers/features side of things. (edited) |
| Yosu Cadilla | My concern is that Mautic has long parted from the cutting edge of MA technology and it is now at serious risk of becoming obsolete, if it isn’t already. (edited) |
| Yosu Cadilla | The advantage of being a free tool (as in free beer), was plenty enought when the other comparable tools costed thousands of dollars/euros/month |
| Yosu Cadilla | Right now, there are amazing tools out there with all the features Mautic has and then some more, at under $100/month!!! (edited) |
| Yosu Cadilla | At this price point, for any decent business, the difference between $0 and $99 is not worth using an obsolete tool. |
| Yosu Cadilla | That is the danger we are facing!!! |
| Yosu Cadilla | And that is why I believe we need to take “features” as a life and death matter and give it maximum priority over anything and everything else. |
| Yosu Cadilla | Cause 6-9-12 or 18 months from now, it might be too late… |
| john | Right features. That’s why I pursue improved extendability. If you notice there are companies building plugins for WP, Joomla, Drupal, and other PHP projects. But I’ve seen very few attempts for Mautic ecosystem. The Marketplace is not only to help Mautic users but also to help plugin developers to get their plugins to the customers. The current process is so scary that no very few users are actually using them. And if very few users use the plugins then there is no reason for plugin developers to build them (features).It is also not about rewrite. Only about moving some folders around. It’s not that much about changing the code.I maintain one plugin and I must say that users have problem with the installation process. I don’t understand why you think that writing ‘composer install some/plugin’ is less convenient than moving folders around with SFTP or via SSH. |
| Slackbot | Hey there, it sounds like you might be asking for support? We ask that you please post requests for support on https://forum.mautic.org - for more information on how the Mautic community uses Slack and our Forums please see this post: Using the Community Forums with Slack - thank you! 
|
| Yosu Cadilla | It is also not about rewrite. Only about moving some folders around. It’s not that much about changing the code.Then by all means, move those folders. The marketplace is undoubtedly a great improvement!At some point of the discussion, it seemed (at least to me) that some people thought that rewriting Mautic was a necessity in order to allow better Composer compatibility. If it is just a matter of reorganizing folders, I don’t see why not.I guess most of the comments I just did here apply to the conversation on the channel and not here on the Composer Thread… |
| Jordan Ryan (Facet Interactive) | At this price point, for any decent business, the difference between $0 and $99 is not worth using an obsolete tool.I agree with this point, the reason why Mautic remains competitive at the enterprise level is because there isn’t a low-cost comparison that can be made.Conversely, I would not choose Mautic for a budget client. There is too much testing and maintenance work in between updates to make it cost effective. Invariably there are regressions, so for this price point I would wholly recommend a SaaS solution over Mautic.I would ask if this is really the audience we are trying to serve? Free is not better. Open source, extensible, choose-where-you-host your data are strategic advantages. I agree Features are lagging, but unless the core team can add in more features, then the core team should focus on enabling more developers to contribute custom plugins. |
| Yosu Cadilla | I agree with most of what you just stated. However, if the issue at hand is to make things simpler for developers, I believe those developers are the small company developers and the self hosting entrepreneurs with programming skills, I really doubt corporate Mautic users have any issues with the current level of complexity.AND, If we are aiming Mautic at at larger companies, then we need no marketplace nor a simpler way to install plugins, cause there are engineers managing those matters at those kinds of companies. |
| Jordan Ryan (Facet Interactive) | The question still remains, is it the responsibility of the Core team to add more features, or to enable more features to be added and contributed by the community? I don’t think these are opposed but that’s the root of the discussion here. |
| Jordan Ryan (Facet Interactive) | Personally I think the lack of composerification makes Mautic very brittle. mautic-eb does a good job of handling it and we copied this for our approach with mautic-k8s. It’s still brittle between updates and maintaining a bunch of bash scripts to replicate what is… simply offered out of box in composer is kind of wonky. |
| Yosu Cadilla | Right, I guess if we are willing to get to the root of the problems, we will indeed find some structural decisions might have to be taken in order to prevent those (oddly recurring) issues come back again in the future. |
| Jordan Ryan (Facet Interactive) | I think @Dennis Ameling (he/him)'s points are worth considering in this context, too:https://mautic.slack.com/archives/CQMKV0RU1/p1604569409186200?thread_ts=1604501184.174700&cid=CQMKV0RU1 (edited) |
| Yosu Cadilla | The question still remains, is it the responsibility of the Core team to add more features, or to enable more features to be added and contributed by the community?One thing I always found to be very odd is thet the Dev team is called Product team. |
| Yosu Cadilla | And we don’t have a Strategic, multidisciplinary team dealing with Product and Market related issues. |
Participants:
ekke, Yosu Cadilla, Nico Grienauer (he/him) Drupal/Analytics/Styleguides, Nick Veenhof, john, Red, Jordan Ryan (Facet Interactive), Slackbot