(Editor’s note: This is a sponsored article, which means it is independently written by our editorial team in collaboration with, and financially supported by another organisation, Parimatch. If you would like to learn more about sponsored posts on tech.eu, read this and contact us if you are interested in partnering with us.)
About a month ago, we already wrote about how Parimatch, an international betting holding, shifted its focus to become a proactive technology company first and foremost - warts and all.
Today, we look at Parimatch's open-source journey, with the help of Oleksandr Tserkovnyi, a front-end architect at the company:
It may seem like Open Source is just a case of pushing your code on GitHub, but that is just where the journey begins. At the end of February this year, Parimatch Tech – the hi-tech R&D centre of the global holding company Parimatch – transformed from a marketing company to a technology company.
We realise that it was a transformation that will change everything about the company and especially the way we think. After making that decision, we began brainstorming ideas around what needs to be achieved in order to be called a tech company.
One option was Open Source.
As a company whose revenue is derived from highly-regulated activity, this seemed like a tough thing to accomplish.
Parimatch Tech provides a number of future-defining tech solutions in the gaming and entertainment industry, and the main business is sports betting. We have around 300 people in the IT department, and 2,000 in general.
It was not simply a case of turning around to our colleagues and saying ‘hey guys, now you can contribute to Open Source’. In the past, this was not possible as all work was tightly protected or held under non-disclosure agreements.
Critical and technical parts of the company were kept under wraps as they are core to the company’s competitive advantage.
Revolution
A small group of people, sometimes even just one focused person, can start a revolution.
We gathered 13 people and created a team called the ‘Open Source squad’, which was made up of different people across the company from senior developers to the CIO. We started to throw around ideas. What will the process look like? Who will be responsible for it?
It was clear to us after the first meeting that Open Source must be divided into two types:
- Contributing to the projects that we use on a daily basis, like Kafka, Node.js, React, Vue.js, .Net.
- Developing our own Open Source projects, libraries and approaches that were designed inside Parimatch Tech.
We started gathering ideas from the entire company and registered our name with many of the code storage hubs, including GitHub, npm, GitLab and several others.
Our name had already been registered on some of these sites without our permission so we went about securing the rights to the accounts.
Then we started to form some validation rules for every project. Firstly, we need to be clear on how many people will work on these projects, and we put processes in place to ensure our work was reviewed by the CTO and security and legal departments.
It was important to ensure that we keep the dynamic of the business and that we concentrate on projects that support both the business and the Open Source community.
It’s also important to avoid repetition. Before moving a library to Open Source, we needed to search the community to see if there is a similar one out there as it might seem like we are solving a problem that in fact has already been solved.
Furthermore, does our work conform to the community guidelines of the Open Source hubs that we are contributing to?
First steps
Despite all of these questions, we moved ahead. We created our first repositories and took our first steps. We held weekly meetings to track our progress and to decide on what work we would communicate with the rest of the company and which ones are kept to the 'Open Source squad'.
Eventually, we realised that we need to get approval from top management to ensure that our Open Source work doesn’t clash with other processes in the company.
We negotiated with our delivery manager and came to an agreement around the first type of Open Source mentioned above – contributing to the likes of Kafka, Node.js, etc. – making these a part of the standard development processes.
The second type of Open Source was a much harder sell. This is the Open Source work that we have already done ourselves, which can be very time-consuming. A decision was made to split the team’s time clearly so no work was overlooked.
The main question we had to answer was 'the why'. Why should the company spend resources on this?
For the company, it’s a win because it helps improve the work developed in the company. We found that hammering out the processes for our work by setting clear rules helped everyone understand their responsibilities better, whether that’s work on company projects or Open Source contributions.
Transparency around these rules will also help attract candidates to work at the company – they can do their job in a very transparent way and follow existing processes – while the company can expect to gain authority in the technical community.
If you haven't already, your company should try and experiment with its own Open Source projects - because you may be missing out.
Would you like to write the first comment?
Login to post comments