Interview: Most Valuable Pimconaut of the Year 2019
Jan Walther, our most valuable Pimconaut 2019, operates his own blog and is employed at digital commerce agency Blackbit. Most of his GitHub contributions to Pimcore were submitted through a shared agency account. We asked him for an interview to learn more about his motivations.
We’ve already merged more than 40 pull requests from your contributions to Pimcore on GitHub. What is your motivation to give back so much of your knowledge to the community?
For me, there are two main motivations to submit pull requests to Pimcore:
- Whenever I stumble upon a bug or anything which can be improved with just a few lines of code, I just fix that. This is mainly because, I do not want to get annoyed by the same bug again in the future. As an agency, you often have to maintain a lot of Pimcore functionalities so fixing a bug in the core of Pimcore scales the improvements, as well as overall Pimcore system in the next update.
- When designing solutions for our customers’ requirements, my main focus is reusability. Reusability of solutions and experience is the main advantage agencies have as compared to in-house developers who mostly have much less Pimcore systems to maintain. For this reason, I always think: “Is this a requirement which other customers could also have?”. If the answer is yes, then a reusable solution would have more benefits compared to developing a customer-specific implementation. Consequently I ask myself: “Is this feature only relevant to a certain industrial vertical, or can we find a generic solution?”. If it is industry-specific I develop a plugin/bundle; and if there is a way for a generic solution, I implement the feature in the core and submit a pull request.
When talking to agencies at the Pimcore Inspire event, I got to know that many agencies see submitting pull requests as giving away their work for free. But this is not the case: as mentioned above, customers pay for solutions to meet their requirements - be it individual in the AppBundle or as a plugin or as core change. When you submit the changes as a pull request, the customer can be assured that the Pimcore maintainers will care for the compatibility of the feature in future Pimcore versions. In contrast, when you keep the changes private, you have to care for upgrade compatibility yourself.
How do you make sure to follow a generic approach when making your Pimcore pull requests?
Our customers do business in a lot of different industry verticals. As we develop solutions together with our customers, we learn a lot about their processes, business models, etc.
Customers naturally see only their use case, so it needs some ability to abstract from the individual requirement to a generic solution. But as agencies get so much knowledge about the customers’ businesses, they have the advantage of being able to implement things in a way that fulfills the customer’s requirement as well as setting the base to future reusability. In the end, it is in the interest of agencies to not reinvent the wheel for every customer but to have generic, extendable solutions.
How supportive is the Pimcore core team who is reviewing all contributions? What do you think about external reviews?
I really have to compliment the core team. They assist developers in reusing existing functionality or in enhancing implementations to comply with other parts of Pimcore - that is why Pimcore never feels like a system of individual components but nearly always offers similar user and developer experience in all parts of the system.
But we must not make the mistake of seeing pull requests as a dialogue between one developer and the core team. In fact, Pimcore is a community project and lots of pull requests get commented by community members - this often helps to fix bugs, to motivate the developer, and even more to get a better implementation in the end.
And last but not least, I have to mention that when merging a pull request, the maintainers nearly always give some words of thanks. Such little things have a big impact on motivating developers and building a community.
How do you find the requirements for your pull requests? How do you make sure as a developer to have some time for contributing while constantly being busy in project work?
In fact, nearly all of my contributions to the Pimcore core are based on customer requirements. It is often easier to change the core than to implement a feature in a plugin or customer-specific bundles. But needless to say that publishing implementations always makes them criticisable - but you must never take critic personal because, in the end, you get a better solution through others’ comments and even become a better developer.
The customer pays for a solution to fulfill his requirements, not for the implementation. The additional effort to provide the implementation to the public is quite low: Of course, you need a sense of abstraction to find a generic solution, and you have to put some communication efforts, as well. But at least in our case, the advantages of submitting our work as pull requests is beneficial to all parties:
- Customers get a future-proof (update-compatible) solution
- Agencies can reuse the feature for other customers
- Pimcore gets more feature-rich to attract even more potential customers
- Developers get better by getting a deeper knowledge of the Pimcore system and through comments of the community
How do you see the future of Pimcore from a developer’s perspective?
Especially the flexible data model with easy mass-editing features makes Pimcore such a versatile tool to develop all kinds of applications. On the other hand, this flexible data model keeps it difficult to provide out-of-the-box solutions. Consequently, Pimcore needs to focus on becoming the central user-experience data platform by extending mass-editing features and artificial intelligence while also integrating feature-rich and easy-to-use import/export/API tools. The data hub approach really looks promising to allow building APIs without any backend programming being involved!
