June 29, 2015
Get in touch
To meet their special demands we regularly develop high-quality, customized extensions for our customers and, in close cooperation with them, often make these extensions available to the Open Source community. In our last blog post we described, why we make AOE extensions available to the Open Source community and which benefits this provides for the customers, the community, but us at AOE, as well.
However, published extensions need dedicated maintenance and create a number of challenges for us and our customers. How can newly developed extensions best be published? Without publication requiring too much time and maintenance? And without the focus of the actual development process suffering?
Many customers fear that too much time is needed to maintain open extensions and that the focus of the client’s requirements is lost. But there are helpful tools that make child’s play of integrating the work of Open Source projects into the implementation of customer demands. In addition, one should consider the following items for sensible publication.
All necessary requirements need to be carefully thought through right from the beginning of planning a feature, so that the extensions that are developed as a result can be effortlessly published. Dependencies on the business logic of the customer must be avoided, so as not to make public a customer’s processes, while still ensuring that the Open Source community benefits from publication. A clean interface design is essential in order to avoid dependency on customer-specific extensions.
One of the primary quality attributes of open software is documentation. For example, Sphinx is a good tool for working with the Content Management System TYPO3, both to view the documentation in the backend as well as to easily edit it.
Many of our customers work with large editorial teams, which means that documentation about the use of features developed by us is essential. The entire TYPO3 community, but mainly our customers, benefit from this standardized approach, which we both promote and use ourselves.
In practice this means that we provide templates for documentation. Thanks to Sphinx the documentation is part of the extension and can thus be managed by every user through open repositories.
The advantages of Web 2.0 become particularly apparent when working with Open Source software. We are in direct contact with the TYPO3 community through GitHub, which allows us to work directly with countless other developers. Nevertheless, due to its backend integration the TYPO3 Extension Repository (TER) remains our preferred channel to communicate with integrators.
GitHub provides breadth of functionality similar to TYPO3 Forge; however, it clearly has greater reach. Because of this we intend to focus on GitHub in the future.
To guarantee the high quality of our work, the source code of our extensions is continuously subjected to monitoring. During this process we check diverse quality attributes, such as checkstyles, messdetection, duplicate code or code coverage. In this way we can ensure that the elements the community adds to the source code truly represents an improvement when viewed with the customer in mind.
To further reduce the efforts needed for publication, we have automated the upload into the TYPO3 Extension Repository with the help of an open library.
Open Source-Extensions aren’t created in a vacuum – an active community that makes its developments available to the public is needed. With the conscious use of proper tools publishing improvements and new developments can help share the workload for applications of all kinds, which leads to more efficient, innovative solutions
