Understanding WSO2 Product updates and open source release model

An “update” means an improvement to an existing product. It can be a bug fix, improvement to an existing feature or a totally new feature. WSO2 is a “product” company which delivers software products which are used in the “middleware” space. WSO2 product updates can be divided into 2 main categories.

• Commercial updates
• Open source updates

Commercial updates

WSO2 is one of the few companies which offers 100% open source software products. But they are running a business and their engineers needs to be paid for their hard work. How they earn money is through the subscription in which they provide following 3 main services.

• Product updates in a reactive manner — When a customer reports an issue through the incident support or query support portal (mentioned below), WSO2 team works through the issue and deliver fixes through “wum”. WSO2 Update Manager (WUM) is a tool which delivers bug fixes, improvements and version upgrades to the product. This update will be available for all the subscription customers through WUM at the point which is released for that specific customer.
• Query support for development — Once the users start implementing their use cases with WSO2 products, they will require some expert help on certain things. With a valid subscription, users get acces to a JIRA portal and they can raise tickets to get help from WSO2 experts.
• Incident support for production and non-production deployments — Once the system is moved to production, there can be situations that system become unavailable due to certain issues in the products and the way it has been setup. With a valid subscription, users get access to a JIRA portal through which they can report incidents which are occurring in their production system and get immediate attention of the WSO2 support team.

In this post, I’m going to explain in detail about the product updates which are delivered to the subscription customers. WSO2 Update Manager (a.k.a wum) is the tool which can be used with valid credentials to download or update any of the WSO2 product. The below figure explains the wum update process.

Source: https://docs.wso2.com/display/WUM300/Introduction

As depicted in the above figure,

1. users can download the wum client and install that within a server which they use to do the deployments. They can install this client on their laptops as well.
2. Then download the products which needs to be used within your environment. You should have a valid subscription for all the products which you are planning to download (and update through wum).
3. Even after you download the latest product version (e.g. APIM 2.5.0 as of now), you should check for updates. There is a chance that there can be updates delivered after the latest product release.
4. If there are any updates, get those updates and check the summary PDF file to verify any config changes you need to make to the product
5. After you make those changes, you can move the updated product to the relevant environment (DEV, TEST, PROD)
6. You can continue this cycle from 3rd point based on your release cycles

WUM is a tool which is going through major developments and WSO2 is planning to introduce “channels” through which customers can request for certain updates which they are interested in (e.g. security only channel to receive security updates).

One of the important things about wum based updates is that those are updates to an already released open source product version. You will get bug fixes and certain level of features which are critical for customer projects. Also these updates are heavily tested and production grade.

Open source updates

WSO2 is a company driven by the “open source” culture. Any organization can use WSO2 products as open source product versions by either downloading through the website (wso2.com) or by building from the source code. As an organization driven by “innovation”, WSO2 engineers work on improving the existing products through day-in day-out innovation. All these improvements are done within a public github repository. If someone wants to get the latest build, they can always build the product from source code by cloning the github repository.

WSO2 team believes that frequent stable releases allows customers to move to the latest product versions through “delta” level changes rather than moving to a “big bang” product version upgrades. Due to this reason, once a certain product version is released (e.g. APIM 2.5.0), WSO2 team starts releasing the gradual updates to the next version (APIM 2.6.0_updateX) through their development mailing lists and users can download these binaries through github repository. Typically, these updates are released weekly but there can be exceptions based on the amount of new features/improvements added to a certain milestone release (update). These updates are open source. Anyone can download these updated versions through github.

One of the major differences between these open source updates and the commercial updates is that, open source updates always adds new features to an already released version and keep on going towards the next GA release. Users have to wait until these updates are released if there is any critical bug fix which was already released through commercial updates. Commercial updates are done on an already released version and it will keep the product version as it is even after the updates. These updates are released immediately and customers get these updates as soon as the fix is identified.

How to be in most stable version in production while moving towards next greatest version through development

Let’s take a look at how you can have the best of both worlds by properly planning your development and production envrionments to have the latest and greatest product versions. Let’s imagine a hypothetical deployment where you have 3 environments namely DEV, TEST and PROD. At the beginning of the project, you download the latest version of WSO2 APIM (which is 2.5.0 at the moment) and take all the available updates through wum tool. You do the development of the APIs and make the system production ready after 3 months. During this time, you can take wum updates weekly and move those updates through DEV, TEST to PROD environment. At the date of the first production release, you should have identical wum updated versions in the production. While you are adding new functionalities to your system, you can update the DEV environment weekly and TEST and PROD envrionments monthly. That is how you can stay in the greatest version of the product.

In the meantime, you should start moving to the latest version of the product by spawning a new Experimental setup with the identical implementations except the product version. You can have the latest open source update (2.6.0_updateX) in this envrionment and keep it upto date with the implementation of your real production system. You can do weekly ( or based on availability) updates to this setup and make sure your current implementation works without any issues in the upcoming release. By the time next GA version is released (2.6.X), you have already tested your functionality in the experimental envrionment and move that to DEV envrionment with the GA version and continue to move into production envrionment.

With this approach, you can keep your system in the most stable version in production and most recent version in development.

Happy update !!!