DevOps and Open Source Projects

Are you just a user of Open Source or also a Open Source developer / contributor? As a Software Developer or Development Lead, Do you ever wonder about DevOps practices of Open Source Projects (delivering Tools, Framework and Libraries)?

In recent past we had customized (not just configured) few open source tools. Our experience on DevOps maturity of these open source projects was mixed. Few challenges and also findings led me to further understand / investigate about DevOps for Open Source Projects. There is very basic discussion around on DevOps for / by Open Source Projects, like -

• http://oss-watch.ac.uk/resources/releasemanagementbestpractice,
• https://10up.github.io/Open-Source-Best-Practices/
• http://www.apache.org/theapacheway/index.html
• ...

Keeping aside the generic question of "DevOps practices for / of Open Source project" let me share some of our experiences during customization of 2 Open Source Tools. You may find them applicable even for your enterprise Microservices driven Software application / product / system.

Background

One of the Open Source Software Product (OSSP) we customized has multiple Microservices. Rather I call this OSSP as a collection of Microservices. The purpose of this OSSP is to track & analyze maturity of organization-wide software development, delivery, and in general Software's Time to Value. Few of the OSSP's Microservices are Rest based and expose gathered / analyzed data from organization's Software Development, Delivery and Deployment.

UI(s) of this OSSP uses REST based APIs to group the data and present various dimensions as a result of the data analysis.

Coming from Monolithic App. world, our initial set of questions include,

How is the release of this OSSP marked? Is it a release of each independent Microservice tagged with a serial number? OR ....

DevOps and Open Source Software Project (OSSP)

As a Developer / Tech. Leader, we also wonder about -

• How do Open Source projects manage multiple teams working on these various microservices as part of larger product?
• How are these microservices grouped and how are portfolio of these microservices tracked / managed?
• How Open Source Projects continuously improve such OSSP's DevOps maturity?
• How Open Source Projects plan Releases (Feature / Major and Maintenance)? If you are a open source developer / contributor, you might have heard about PR but overall complexity is much more.

Few of these above questions are common across Enterprise Projects and Open Source Projects. In Enterprise projects you may be using either open source tools or one of the commercial on-premises / SaaS tool for feature management, release management... etc. Many times you might have faced version mismatch issues while using Open Source Projects. This struggle and challenge exists in Open Source Tools, Frameworks and Libraries but still there is a large userbase for Open Source.

In the above scenario of the OSSP product, there is additional complexity because of dependency amongst Microservices. One need to weave a right thread across Microservices as part of packaging and mark a release of the OSSP (esp.ly for on-premise use). You can definitely release Microservice independently, but one need to ensure that runtime dependency is not broken.

• Such challenges are dependent on Open Source product architecture and ecosystem. For example, in certain open source products issues may be - which published Plugins work with new release of this open source product (limited by schema compatibility or new constraints or due to change in architecture).

Most of these Open Source projects extensively use open source frameworks for code-analysis and unit testing. This integrated build and test approach is a normal DevOps practice and is strictly adhered to by the successful open source projects. The approach is necessary for component integrity and quality but not sufficient to address integration issues.

So, How Open Source projects deliver and lead "Production-Ready" product?

Open Source Projects also have Product Managers. As a ex-product manager I can understand his challenges. Many times Open Source Projects die as they are unable to address Technical Debt. But, many times Open Source Projects fail due to few end-users, participants and due to lack of feedback for better feature planning. It's really tough to decide right set of features unless you have a strong user / contributor community and discussion forums.

There are many more dimensions, like most of the successful open source projects are always deployment ready (on-premises, cloud and any docker / non-docker environment). In general, Open Source projects provide a great learning to continuously improve your Enterprise projects DevOps maturity.

Summary

Many times I find that Enterprise Projects are more worried about basic Agile practices or continuous integration. But Production First mindset, good maintainability / extensibility and many other aspects are missing. This is a key reason to study successful Open Source projects and, how they manage synchronized releases.

Btw. If next time you use any Open Source Library, Product, Framework .... do ensure to submit regular feedback / response / challenges. Be a participative user. and contribute to Open Source Software project's DevOps cycle.