Ratioweb as sponsor at DrupalCon Portland’22

Our team consisted of three persons. Me – Marcin Gokieli – and Karol Bryksa are (mostly) backend developers, while Marcin Fajfruk deals with the project management, PR, and related topics. We stayed at the very conveniently located Mark Spencer, just a couple of streetcar stops to the Oregon Convention Center. The weather was pretty similar to what we had at the time in Poland: quite cloudy, but not cold, pretty good for spending time at a meeting of this kind. The registration was quick and easy. The conference staff were very friendly and helpful, so all we were ready to set up our stand.

Let me introduce ourselves: we are Ratioweb, an independent software organization working on a cooperative model. Flat structure, open source, agile are key elements of our organizational structure. Our whole team is about 15 people plus some more or less regular cooperators. We are working with clients from Poland, Europe, and the US (with Polish clients representing, say, around 30%-40%). We specialize in working with non-governmental organizations, educational institutions, but we do also have corporate clients, relying on technologies such as Drupal, VueJs, Grav.

What was our goal in going to DrupalCon? We sure did want to present ourselves both to the potential clients – especially the ones that it could be difficult to in touch from Central Europe. We did want to follow the development of Drupal and related technologies – the DrupalCon provided us with a great occasion to learn about the both the new currents and ways to solve old problems. An important goal in itself was meeting the members of the Drupal community, especially with this being the first event of such a scale after the pandemic. We shared the time between staying there, going to talks and workshops, and strolling around to see what people offer and what do they have to say.

The key aspect were if the event were the talks. There was of course the “Driesnote” by Dries Buytaert, the person who initiated the Drupal project, with an overview of its current state. The current version is 9 (with both 8 and 7 still being supported), and the talk was circling around the innovations that are to come in the version 10, with am overview of where we are heading for the yet next version, the 11.

Now, I assume that the reader of this post has an idea of what Drupal is, but a short note might be of use: seeing the project history will enable us to see how it sees its future. Basically, it’s a software system, written mainly in the PHP language, which you can use to create websites, web applications, and other web – based software (like backend for mobile apps). The selling point is that it’s a kind of two-edged sword. On one hand, it’s simple enough to get started. You can create a powerful website with various, custom – defined displays of content and logic without any programming, just by using a point-click web interface. In fact, I personally began my Drupal adventure when asked by a tech magazine to write about “this new system” more than 10 years ago. Using what I learned in the process, some two years later I sold a quite complex e-commerce site for e-language learning. It included video sharing, public/paid videos (with free previews), a system of discounts for corporate buyers, an online payment system – and so on. If I remember correctly, except for custom CSS styles (built from ground up), there was no coding involved. All done by point’n’click: Drupal Commerce 1, thank you very much. The good thing about that is that such a way of developing stuff is quick. That speed is not only a nice feature in itself, it makes possible to explore and discuss possible structural changes with the client efficiently. You can sketch some solution, present them to the client, discuss and bring in the requested changes.

With the Drupal 8, a major rewrite from 2015, the platform adopted Symfony, an object-oriented PHP framework as its basis. It became more complex in structure, with the well-defined fabric of services, plugins, controllers. You would still do a lot by point’n’click, but doing programmatic changes required more preparation. The upside is that it’s much more maintainable – and if that sounds too technical to you, just think that the code was much easier to understand. Creating a simple system became a bit more complicated, but dealing with a complex one became feasible. The large part of that advantage came from the fact that a lot of standard tools and good practices used in other PHP projects, and they in turn are use solutions developed in other languages. Drupal strives to achieve a golden compromise, which seems very desirable from many points of view. On one hand, you can sketch the data / display / basic project structure quickly and then discuss the options both with the client and inside the team. On the other, the resulting final code can be made fully standard – compliant and easily maintainable.

Let’s get back to the keynote. As appealing as the ideal above might be, it is not yet fulfilled There were still some major problems for the platform. The way I see the outcome of the Dries’s presentation, we assume that the whole system is largely heading in the right direction. The upcoming changes are important, but focus more on improving than on radical changes. I see two main directions here. One is reorganization. One example of this kind of task is the effort to trim the Drupal core. The idea is to remove the ones that are not necessary for everyone from ‘core’ (what you get when you install the Drupal itself) to ‘contrib’ (additional modules you can add if needed). Such a change should not change anything besides the very first steps of construction of the site. If the “forum” facility gets moved from core (where it is still in D9) to contrib (where it is expected to be in D10), it should just mean that users that don’t use it won’t have it installed by default and thereby enjoy a slimmer and less error-prone system. Those who intend to use it will just have to do it manually – it’s just one ‘composer require’ away.

That is the theory, anyhow. The practice is, in fact, a bit more complex. Moving the stuff from contrib to core (like it happened with Views in D8) or the other way around (as it will happen with Forum in D10) is not just a question of tags. All sorts of questions follow – just consider that when a module is in core, its security problems are problems for the core, and its development schedule influences the releases of Drupal itself. Such projects require more care. The flip-side is then when they are “set free” and become independent contrib modules, it is necessary to provide resources, so they can be sustained and grow. Such an action requires thus a lot of structural and organizational work to make sure everything works smoothly. As such, it is a good example of one direction the whole Drupal is heading.

The other important direction Drupal is heading is integration with the outside world. It is well represented by a shift to CKEditor 5 in Drupal 10. This again can be seen as strategic change: the stake is to ease the cooperation with developers from the broader PHP world and beyond as much as the technical excellence itself.

Drupal aims to be more standard – adherent, thereby better more accessible for new developers and better documented. All Drupal developers know the so-called ‘drupalisms’ – special constructions that are Drupal-only. Getting in line with the generic tools is something that would much ease the adoption of the platform. Of course this requires direct developer work, but the goal is defined by ‘political’ factors – the ‘external’ relations with other projects and internal with the community.

My personal opinion is that this strategy is a great one. Drupal is in a pretty good state now, and needs evolution, not revolution. I think we can sum up the current state of affairs by saying it’s already a grown-up. No need to make sudden, challenging moves, cooperating with others and making oneself easy to deal factors are key factors. Still I would love to hear about some major improvements to such elements, as Form API. Those would be difficult because of the huge codebase already in place – I am sure their time will come.

If this discussion Dries’s talk got you interested, you can watch it, as were other talks and discussions, online at Drupal Association’s YouTube channel.

The fact that you can get so much of the content happening there online makes you wonder if it was really worth taking the transcontinental flight to get there? And the answer is that the most valuable thing was not so much getting the information available and hear all the great talks and discussions, but the diverse Drupal community. You saw really very different kind of people with very different backgrounds. As mentioned we are a rather small company – the stand next to ours was taken by the EPAM Systems, a multinational organization with thousands of employees. It was an obvious display of haw scalable Drupal is. Drupal goes at length to be open to anyone, independent of religion, nationality, sexual preferences, and so on (there’s also a special project that aims to promote that aspect, see . Panels were available with sign-language translations. By the entrance, you could get pins which lets you identify pronouns you want people to use when addressing you, and another set for showing if you’re willing to talk to others or rather you’d keep quiet. There was a prayer room available.

The results of that approach were very tangible. You were really seeing a very varied, definitely not corporate-only (though definitely corporate-friendly) crowd. That means not only that the project can use more people as developers, testers, documentation writers and so on. It also means the discussions on the solutions will not be done by a closed group, so the results may be useful to more people. That it turn can be a direct business advantage. Let me just dwell a bit on the pins for pronouns and talk willingness. This stroke me both very useful and something really simple measure. It costs almost nothing, while going a long way towards solving some problems (or at least giving a way to deal with them).

Being in Portland itself was fascinating. Let me say I had a huge bookstore (Powell’s, touting itself as the biggest independent bookstore in the US, and it did not seem to be a bold claim), a bicycle store, and a record store, and a climbing gym.On the last day, Marcin and I had a long walk through the city and around the river, and Marcin made some great photos.

It may seem paradoxical that in-person meetings are so important for the world of a top-notch web technology such as Drupal. Perhaps this is just another proof that the virtual world of the internet is not here to replace our good old reality, but a tool that can help us with dealing with its problems. Seen from Portland, Drupal seems to be perfectly prepared to fill that role.