Attention "dusty"!
This article is already a little outdated and may contain information that no longer corresponds to the current status of the topic.
Open Source in Drupal: "Contrib" and its advantages
Open source allows every developer to have full access to the platform's code. As a developer, this has massive advantages: Everyone in the community uses the same tools, so they're also in touch with the same day-to-day issues. So why deal with every little thing yourself when there is guaranteed to be someone in the big wide world who has already dealt with the same issue?
These are the advantages of Drupal's large "Contributed" landscape. Want to be able to impersonate other users on the site to see content from the end user's eyes? The "Masquerade" module adds this function. Do you want to connect the customer's mail server to send emails? Then it's better to do this with the "SMTP" module instead of investing in the development of your own solution.
If, on the other hand, you use proprietary software, there are many barriers in the way. For example, developers are much less likely to find solutions to their everyday problems. Solutions are often only available from the company's employees, for example via a support email. This all costs time and effort, whereas you could otherwise use the wealth of ideas and experience of open source software with a Google search.
However, if you don't have to pay for all these benefits, at least there is a sense of responsibility and loyalty to the people whose knowledge and skills have made such advantages possible. You can apply the French saying "Noblesse oblige"; with privilege comes responsibility. When you receive so much, you should also give back and leave your own imprint on the shared treasure of knowledge and technology, so that others can also gain from your understanding of the system. This is a fundamental trait of humanity.
Localized Configuration
As a digital agency, arocom aims to take full advantage of Drupal's modular nature and developer focus to create unique solutions, rather than forcing it into a prefabricated standard format with minor customizations. Every website operator has their own ideas about how content should be structured and managed on their site, and what information should appear where. And even within an operator, there are different teams, departments and stakeholders who do not always share the same views and wishes.
For this reason, it is important to us that the customer can make their own adjustments to various aspects of their website as required. If, for example, the URL to the Facebook page changes, the customer should be able to make the change themselves quickly instead of having to go through the agency.
It is therefore not surprising that a concept has crystallized in our company over the years on how to manage such settings optimally in a central location. The aim was to provide an accessible UI that makes the settings of a page globally accessible to our customers, but also per language.
The "Localized Configuration" module offers a central interface for website settings. It is a framework for developers who want to write their own features and manage them centrally and language-specifically without any effort.
All the developers have to do is write their own plugin with the desired form elements. Localized Configuration manages the display of forms in a central interface and offers convenient options for querying these values in the code and using them for other functionalities.
The eponymous feature is the "Language Overrides". In addition to the global standard that is set, there can also be deviations per language if, for example, a set sentence needs to be translated. However, if you use the Drupal system of "Languages" more as a replacement for "Multisite", you can also switch entire features on or off for certain pages, for example, and significantly change the behavior of certain modules.
In our customer projects, this module is used on many websites. The overrides and the "localized" aspect of the module are optional, and the interface can also be used on its own as a central collection point for settings for a single page.
The path to contribution
Removing a module from an internal use and making it available to the general public required some work on many levels, such as in the concept, the technology and also the organization.
This made it clear that publishing the module shifts the company's responsibility and process in its development. After publication, development must take place on the publicly visible platform. Features that only affect our company must be removed and implemented separately internally. Changes to the structure of the module must be made with the general good of the community in mind. And instead of being able to "just" implement fixes internally, the update process now goes through the standards of www.drupal.org, the publishing platform for the community. All users are informed about every update, and comments and messages that previously required the understanding of colleagues must now be written for the public and carefully maintained.
Certain solution approaches that correspond one hundred percent to our use cases within the company are not to be expected from all users, so some behaviors (e.g. filtering languages according to certain patterns of language codes) were made optional and adjustable in the backend.
This was followed by the actual contribution process on the community website www.drupal.org. The platform is of course curated and designed for quality; there are many guidelines, tutorials, instructions and tips on how to publish and handle your project in the best possible way. There was a lot to read and a lot to optimize before the project page reached an appropriate level of maturity. And as a new user on the platform, you first have to go through a validation process that confirms your expertise and understanding of the Drupal way of life, so that the modules you have written are no longer flagged as potential security risks.
The module is now live, and it is hoped that the global community will find it useful. If there are many users, the original developer will also gain from the contribution; there can now be contributions from developers all over the world who expand and improve the code of the module and even add new features. Once such a project is out in the big wide world, it can develop a life of its own, which can lead to all kinds of progress.
Conclusion
Contributing code to the wider Drupal community is not a particularly easy process, but it is deeply satisfying and brings benefits not only to others, but also to the developer and their own customers.
In this step, arocom has now removed one of our central modules from the internal landscape and made it available to the public:
We hope there will be a lot of interest and look forward to your feedback.
