Reuse as Open Source

With open source projects as role models in mind there are different options for reusable code in a microservices project:

  • • The organization around reusable libraries is structured like in an open source project. There are employees responsible for the continued code development, the consolidation of requirements and for incorporating the changes of other employees. The team members ideally come from different microservice teams.
  • • The reusable code turns into a real open source project. Developers outside of the organization can use and extend the project.

Both decisions can result into a significant investment since markedly more effort has to go into quality and documentation, etc. Besides, the employees working on the project have to get enough freedom to do so in their teams. The teams can control the prioritization in the open source project by only making their members available for certain tasks. Due to the large investment and potential problems with prioritization the decision to establish an open source project should be well considered. The idea itself is not new—experiences[1] in this area have already been collected for quite some time.

If the investment is very high, it means that the code is hardly reusable for the moment, and using the code in its current state causes quite some effort. Probably the code is not only hard to reuse, but hard to use at all. The question is why team members would accept such a bad code quality. Investing into code quality in order to make the code reusable can pay off already by reusing it just once.

At first glance it does not appear very sensible to make code available to external developers. This requires that code quality and documentation are of high enough quality for external developers to be able to use the code without direct contact to the developers of the open source project. Only the external developers seem to profit from this approach as they get good code for free.

However, a real open source project has a number of advantages:

  • • External developers find weak spots by using the code. Besides, they will use the code in different projects so that it gets more generalized. This will improve quality as well as documentation.
  • • Maybe external developers contribute to the further development of the code. However, this is the exception rather than the norm. But having external feedback via bug reports and requests for new features can already represent a significant advantage.
  • • Running open source projects is great marketing for technical competence. This can be useful for attracting employees as well as customers. Important is the extent of the project. If it is only a simple supplement of an existing open source project, the investment can be manageable. An entirely new open source framework is a very different topic.

Blueprints such as documentation for certain approaches, represent elements that are fairly easy to reuse. This can be elements of macro architecture, like a document detailing the correct approach for logging. Likewise, there can be templates that contain all necessary components of a microservice including a code skeleton, a build script and a continuous delivery pipeline. Such artifacts can rapidly be written and are immediately useful.

Try and Experiment

• Maybe you have already previously used your own technical libraries in projects or even developed some yourself. Try to estimate how large the expenditure would be to turn these libraries into real open source libraries. Apart from a good code quality this also necessitates documentation about the use and the extension of the code. Besides, there has to be a bug tracker and forums. How easy would it be to reuse it in the project itself? How high would be the quality of the library?

  • [1] http://dirkriehle.com/2015/05/20/inner-source-in-platform-based-product-engineering/
 
Source
< Prev   CONTENTS   Source   Next >