Promoting moonlighting could benefit your company, and cost you developers.

Hypothetically, lets say I worked at a major cloud provider, we’ll call this company Omozon.

Omozon offers many cloud services. My team in Omozon is responsible for analyzing customer usage data, in order to do that we rely heavily on Omozon’s big data database called MegaDB, and a telemetry platform called ServiceInsights.

MegaDB and ServiceInsights are used by thousands of customers, including dozens of Fortune 500 companies. In spite of this, there is no native integration between MegaDB and ServiceInsights. Our team needs MegaDB telemetry in our ServiceInsights so we can leverage the existing alerting and DRI capabilities we built on ServiceInsights.

After talking with the PMs on MegaDB and ServiceInsights we find that any native integration between the products is at least a year out. Our team can’t wait that long, so one of our developers spends a sprint building a small generic pipeline for pulling our MegaDB telemetry and storing it in ServiceInsights. Thus solving our integration issue.

While building this pipeline the developer found that many of those external customers using MegaDB and ServiceInsights have the same exact issue their team faced. After bringing it up to the team, we decide to speak with management about open sourcing the pipeline.

Unfortunately this goes nowhere, our organization is not involved in the development of MegaDB or ServiceInsights so there is little incentive for management to put further resources into this. What’s worse is the developer on our team cannot take this code and release it on their own given it was developed on company time and is therefore Omozon’s IP.

The end results is a lose-lose-lose situation. The developer is demoralized seeing the potential of their code being squandered, Omozon loses out on potential good will and increased revenue (that pipeline between MegaDB and ServiceTelemetry relies on several other Omozon services), and the customers lose out on a better product experience.

This could have been avoided if Omozon had invested more in open sourcing valuable pieces of its internal codebase.

However, this could have also been avoided by the developer writing this pipeline on their own time.

While not the ideal path, the main developer of this pipeline could have written this generic pipeline on their own computer after work. Once the project was complete they could have published it to their github, then when back in the office, cloned the now open source solution and leverage it on their team within Omozon. 

Now, the customer has access to it, Omozon benefits from the better customer experience and their reliance on additional services, and the developer has full ownership of this valuable open source project, building their reputation as an expert in this field.

In the second situation the developer invested in themselves, and because of their newfound reputation with those in the field, it’s likely they can and will leave for greener pastures. Costing Omozon a valuable developer, a loss which could have been avoided.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.