- Sporadic release cycles. Open source projects are notoriously unpredictable in their release cadence. Release cycles can be very long or very short depending on the maturity of the technology or volatility of the market. Teams that use open source artifacts must structure their applications in such a way to absorb this variability without significantly impacting their user base.
- Contribution management. Whether receiving or supplying contributions for an open source project, it is important to consider how these contributions are managed within the developer's application domain, such as which contributions are added to the application and when. The luxury of the having access to open source code can be a double-edged sword and assumes a certain amount of responsibility and accountability. On one side, there is the ability to change the open source code. On the other side, there is the ability to change the open source code. Think about it.
- Dynamic roadmaps. Open source projects tend to have very fluid roadmaps. The features, enhancements and fixes targeted for a particular release are rarely committed to well beforehand. Some of the more mature projects are getting better at this. It is also worth monitoring the roadmap for any change in direction or vision. Developers must find a way to loosely couple their application's dependencies with open source software.
- New Technologies. The technologies and standards used in open source software may not align properly with the skill sets and domain knowledge of the development team. Even if the open source technology is proven and scalable, if it is not well understood internally it can have a detrimental effect on the developer's efforts going forward.
- Extra-functional requirements. Teams often overlook the non-tangible or extra-functional requirements and constraints that open source software place on the application or its environment to fully leverage the new capabilities. Performance, availability, scalability, testability, recovery, network utilization, etc. affect how the functional requirements (e.g., add, edit, calculate, get, show, etc.) behave. Evaluating upfront the constraints and boundaries placed on an application due to certain open source ingredients will save the developer from unexpected surprises when implementation or release phases are executed.
Failing to fully account for these challenges will certainly affect a project's success. Choosing an open source component as a quick-fix solution could eventually turn the developer's efforts into a continuous state of refactoring as new open source releases and enhancements become available. At its worse, this scenario could lead to the long term effect of the developer spending more time changing his application for the purposes of open source upkeep rather than the more revenue-generating efforts of crafting new and innovative features and functionality. The good news is that the challenges of open source can be navigated successfully.
Using Architecture To Address Open Source Challenges
An architecture-centric approach to an open source strategy will address these challenges. An architecture-centric approach means identifying the architectural style, supporting framework and set of best practices that will govern how open source technology should be used within the context of both the application's development and runtime environments.
An architecture-centric approach allows a developer (business or product line) to sustain the benefits of open source software for the long haul while enabling the separation of the application developer's concerns (i.e., business functionality) from the efforts required to select, integrate and leverage open source ingredients.
An architectural style is the set of guiding principles, rules and structure that, when properly followed, enables application longevity beyond any specific open or closed source technology lifespan. An evolutionary list of architectural styles includes structured programming, object-oriented, distributed object-oriented, enterprise component and service-oriented styles. As