Tags
architecture, code reuse, design, framework, open source, refactor, roadmap
When designing a software application a question that will appear soon is: what modules of the software shall we build from scratch and which ones could be adapted from existing open source developments. What factors should be considered to guarantee an answer that is satisfactory for the project? What project’s needs should we closely evaluate? What characteristics will indicate an open source development is appropriate? How can open source evolve so that the model is maximized? These are the questions that I will give my view about in this post.
What needs of our project should we focus when considering open source
-
Time to market. How much time do we have to release the development? The shorter the time available the more open we may be to reuse code and hence reduce the time and effort required to conclude our task properly.
-
Life expectancy. How long is the project going to be in service? A proof of concept, a pilot or a prototype could be an appropriate scenario where any functional although not necessarily stable code can be leveraged. A production software that will have to be used without the possibility of updates will be much more demanding in terms of code reliability and performance.
-
Customization needs and flexibility. How may our needs evolve in the near future? It is important to foresee not only the current functionalities but the ones that our customer or users may request in the near future. We should aim for including these requirements from the beginning to reduce future refactoring effort. When it is difficult to define a preliminary roadmap you should either assume that we may require to redesign the whole project, specially when the decision involves a platform to use as main pillar of our development, or take the option that offers the maximum flexibility.
-
Team experience.
Some developments have got to a complexity that should not be underestimated if the advantages of code reusing are to preserved. The experience of the team in the technologies to leverage and the programming languages used for the development are a key success parameter. Extending or even configuring or deploy a framework is a complex task for most commercial environments.
-
Deployment environment and control of it. When the environment where your project is going to be used and the dependencies (browser, OS, etc) cannot be controlled because users have the possibility to migrate the versions and no special interest to keep a certain configuration that may not be adequate for other applications, it should be a priority to keep simple our design and architecture in terms of configuration and external dependencies.
Factors important to choose an open source module
-
Maturity. It’s the most important and also the factor that summarizes all the other factors. Before an open source software can be adopted it needs to be trustable, and trust starts with self-confidence. Alpha and beta versions except when the timeframe would allow to modify the strategy should not be considered. Obviously, for long developments time may be enough so that the open source module matures during the development of your project. The rest of indicators should be evaluated.
-
Continuity. A track of record of evolution of the software to be up-to-date with OS versions, framework releases, etc. The more long term our development is supposed to last
-
Licensing. Open source projects are provided under a series of licensing agreements. Whether it is GPL, CC or any other it must be respected and certain commercial developments may not be able to fulfill all requirements specially when they are related to provide the resulting software under the same license or even when it is about releasing any changes made to the software. In my opinion this is a factor that most companies overlook with a fearful perspective and asymmetric expectations. It is unrealistic to use a development, for a long time, without contributing actively to it. Either the development may disappear or evolve along time in an undesired way.
How Open Source should evolve
-
Aggregation. The first and most important part would be to aggregate projects that are alike in a unique one. The more initiatives there are the weaker they are. This doesn’t mean that there should be only one project per functionality, competition in every environment is positive, but it should be limited. Prior to create a new open source software initiative, a thorough study of existing initiatives providing the same functionality should be carried out and whenever possible the existing initiative should be evolved to implement the missing functionalities rather than starting from scratch. This would also help to have more people to contribute to a project, contributing not only their ideas, but also guaranteeing the continuity of the project along time.
-
Consolidation. Developments that are modules, extensions or plugins of framework, languages or tools should, as they reach maturity and demonstrate value, be incorporated to the core of them so that its maintainability is guaranteed as the main pieces evolve. This should happen not only when the core is also an open source development but even for commercial developments that offer an API so that new software pieces are developed around them.
-
Compatibility. Not only backwards compatibility is important, also forward compatibility is important, since many developments are created around any other open source code, to ease that new versions do not require other dependent bits being refactored. Nothing is less rewarding for a software developer that having to debug a piece of code that all of a sudden doesn’t work and that depends on a software you don’t control, even if you have the source code of it.
-
Best practices. Building on top of the previous suggestions, a more formal approach to software development where Unit Test and Documentation are given a more important role as part of the open source software life cycle.
-
Connectivity. Have you ever figured out how many programming languages are there? Here you can see a list: https://github.com/languages . I will avoid the obvious question about the need for having such a huge number of languages given that in many cases they have more similarities than differences: http://hyperpolyglot.org/scripting . With the arrival of new paradigms such as Cloud Computing connectivity will get to more flexible schemas that will not depend on OS, programming languages or frameworks. This may require not only to provide open source libraries but also open source services.