Product development collaboration with Internal Open Source

As a software development company, Core Product and Information System are important components in the value chain of Magestore.

Although they are important, but instead of absolutely closed and responsible only to a few participants, Magestore believes in the value of kindness and continuous development of the whole company. All employees contribute to the collective knowledge. Therefore, Magestore organizes product development in the form of Internal Open Source.

The Internal Open Source is the use of best practices in open source software development and establishing an open source culture within the company. From the outside, Magestore still develops closed software, but internally it’s open. This term was coined by Tim O'Reilly in 2000.

Open source is recognized as being able to deliver high quality software. Furthermore, open-source collaboration allows collaboration even between competitors (for example, ARM and Intel work together on the Linux core). Therefore, Magestore wants to benefit from the open source outcome resulting from the practices of those who work directly with customers.

Why is it necessary to have an Internal Open Source?

Today, the needs of each customer are very diverse and different. Therefore, a product goes from good engineers in a closed room, behind the scenes with no contact with customers, despite having perfect technical capacity, but still cannot be close to reality.

In a software development lifecycle, there are other good engineers working directly with customers at the implementation and maintenance stages. They are the people who know best about product usage and have immediate information about bugs. Therefore the Internal Open Source is a good approach so that these engineers can directly contribute their initiatives to the overall development of the core product.

The benefits of Internal Open Source

• Products meet actual needs by utilizing knowledge of people who work directly with customers.
• Continuous improvement quality thanks to using of the strength of the whole company, to participate in error correction and regular improvement at any time.
• Enhanced cohesion when all employees feel a part of the company's core product.

Challenges with Internal Open Source

• Quality challenges: In the long run, the Internal Open Source aims at high quality thanks to the innovative contributions of engineers. But in the short term, the release of core versions of the product with the participation of many people with different capabilities, if not tested carefully, will paralyze the product by serious bugs.
• Human challenges: It is logically easy to set up an Open Source product. But in order to stimulate a culture of cohesion, because of shared responsibility, many people contribute to the product. Especially when the contribution to the generic product does not have obvious material benefits to motivate,
• Security challenges: Although it is Open Source, it is only open internally. With the outside the product is still closed. Therefore, security policies and rules need to be observed when product information is open company-wide rather than closed within a specific department.

How to organize the Internal Open Source at Magestore

Process control

• In order to overcome the challenge of quality when many people with different abilities are involved in modifying the core of the product, the control process needs to be closely aligned with the The principle is clear and published. The roles and rights and responsibilities of each participant in open source product development should also be clear.
• The testing process is standardized so that it can be applied to automation tests to speed up the quality verification process with a lot of code sources.
• In addition, an emergency fix and product release (Hotfix) process is also required when a critical bug is identified.

Release train release process?

When many participants contribute their work to the product, their features should be released on a regular basis as a means of recognition, instead of being ignored and no one noticed.

Therefore, there should be a weekly product release process. In particular, clearly disclose all updated features, as well as record the contributions of the contributors to that feature.

Application structure on GitHub

Once a clear process is in place, it will be necessary to deploy it on a source code management application. Github is used with the ability to create branches, instances, open permissions, and explicit permissions for each participant.

The Milestone management part of Github is applied to be managed. Automation Test applications are also used with GitHub to control quality with each release.

Measurement reporting

Reporting system will synthesize weekly each participant giving comments (report issue) or code (contribute). From the number of issues or code contributions, it will be determined how enthusiastic each member is in the company's overall development. By looking at the increase in the number of report issues and code contributions, leaders will know how the company's Internal Open Source culture develops.

Development of company culture: develop products together

• Develop a culture of recognizing appropriate behavior: From the reported number of issues and code contributions, company leaders must recognize the contribution of each employee in many different forms. This encourages employees to participate actively for shared and voluntary development.
• Develop a culture of workshop product planning: The product planning workshops are held quarterly to create a public forum for people to contribute product ideas, contributing to promoting the culture for mutual development.

Role of system engineers

• Design and implement process on Github application: From the understanding of the quality control process as well as the continuous release process; System engineers need to know how to install and deploy this process on GitHub. Incorrect settings resulting in incorrect process operation can result in fatal errors on the product and delay in release schedules.
• Design and implement Dashboard reporting system: System engineer will connect with GitHub to get data each time report issue or code contribute. Then you will have to visualize these numbers on a dashboard to illustrate how the product's growth and how the culture has contributed to the growth of the company.

?Conclusion

The success of the internal open source program is an important demonstration of the Digital Transformation and Agile Transformation at Magestore. This is reflected in characteristics such as products that are constantly updated, work closely with the entire company, and contribute to a common culture.

This is also Crosby's Quality Management practice with the principles of: openness, transparency, and responsible contribution from all employees.