Why Submit Open-Source Contributions?

Isn’t it frustrating to find a mistake in someone’s code without being able to correct it? Isn’t it irritating when your brilliant piece of code doesn’t work because of a problem with a third party tool? But then again, isn’t it rewarding to create a useful application to share with fellow developers to make their lives easier?

Open-source contributors have various reasons why they submit their patches. To get a better understanding of these reasons, we talked to some of the software developers at Sigma Software who have contributed to various projects.

Fixing a problem in Microsoft Patterns & Practices (PnP) Provisioning Engine

Oleksandr Yatsenko, Software Developer at Sigma Software, found a nasty bug in Microsoft PnP Provisioning Engine while working on an internal project involving SharePoint customizations:

“I was using the new and actively promoted Microsoft PnP Provisioning Engine to deploy our SharePoint customizations. When working on the project, I found a bug related to the engine not deploying a certain type of customization to SharePoint.

It was intriguing to me to find out what was causing the bug because in some cases, the bug didn’t appear. I finally found the bug after about an hour investigating the engine’s code. I quickly consulted our CTO, and we made the decision to make a pull request containing a fix.

It took about twenty minutes to change a few lines of code to fix the bug. However, testing the fix took almost two days; I had to build the whole project, run all unit tests, and configure my local instance of SharePoint to be compatible with those unit tests.

I was happy to find my fix accepted by one of the project maintainers. If we hadn’t fixed the bug, I would have had to use a rather inconvenient approach to deploy SharePoint customizations. That would have resulted in wasting hours of development time that could have definitely been spent more productively. I hope the applied bug fix turned out to be helpful to my colleagues and all of the people working with Microsoft PnP Provisioning Engine.”

Open Source Contributions

Suggesting corrections to the official docs on interpolated string behavior after optimization in Roslyn

Oleh Petrenko, .NET Developer at Sigma Software, discovered inconsistencies between actual string interpolation behavior after optimization in Roslyn and what is described in official documentation:

Microsoft is constantly improving all of its products and their existing features, as well as adding new ones.  So, when I started investigating how strings work, I faced a strange thing. A lot of information on the Internet says that string interpolation is just the syntax sugar for String.Format, but I soon learned this is not true after optimization in Roslyn. The official documentation regarding interpolation did not accurately describe the inner workings of string interpolation either. I decided that it had to be fixed and was worth creating a pull request.

It was interesting to investigate the code written and reviewed by professionals from Microsoft. The authors made about five thousand commits between the two releases. With that being said, the hardest thing to do was to find the right changes in Roslyn to understand why it started working in an unexpected way. It was also necessary to prove to the reviewers that the official documentation should be changed.

I hope the clarifications I introduced make my colleague’s work easier. I also hope anyone interested in how string interpolation works will no longer be confused because the official documentation now contains relevant information.”

Creating and sharing a library to simplify working with RecyclerView

Ervin Martirosyan, Senior Android Developer at Sigma Software, together with his colleagues, have created a CellAdapter library that simplifies working with RecyclerView in Android applications. The library was open-sourced on GitHub:

“We created a library called CellAdapter with the purpose of simplifying work with RecyclerView. CellAdapter abstracts the boilerplate needed for  mapping model on view holders. There are packages for both Java and Kotlin. Frequently, a single CellAdapter is enough to cover any RecyclerView needs.

We decided to create a library because displaying lists of data is a very typical functionality for most applications. Android SDK provides a developer with RecyclerView for showing a list of data. Oftentimes, you can find a lot of different subclasses of RecyclerView.Adapter in the same project: one adapter for each list presentation. Almost all of the projects I’ve developed have contained ListView, bringing a lot of code duplication and increasing chances of copy-paste errors. As a result, we decided to create a reusable library to address this issue once and for all.

It was quite easy to implement the library, but publishing it took some time because I had never done it before. Initially, the library was published on https://bintray.com, but I moved the next version to https://jitpack.io/. Jitpack is much easier to use so I’ve decided to keep using it.

Any Android Java/Kotlin application developer who uses RecyclerView in a project and adopts our library won’t need custom adapters or to add additional view types.”

Sharing Library

Contributing a bundle for DataDog metrics support in Apache NiFi

Ramiz Abadulla, Big Data Developer at Sigma Software, created a module serving metrics to popular metric monitoring services:

“There’s a system that’s popular among data engineers and scientists called Apache NiFi. Its main goal is to enable more flexible and convenient data processing and distributing operations. It allows developers to build data flows from scratch and customize them in various ways. When we started using it on our Sigma team, there were no explicit options to send metrics to popular metric monitoring services. So, we decided that it would be a great option to implement such a module ourselves.

There were a lot of review stages from the Apache team, and a lot of suggestions on how to improve the module functionality to make the code perfect and consistent with their expectations. Each of my new implementations were reviewed and tested, until my PR was finally accepted by engineers. As a result, I’ve created a module that is able to collect metric stats from different data sources used in the NiFi pipeline. Those stats are then sent to DataDog so end users can see all necessary metrics on their dashboards.”

Creating the module was a very engaging experience for Ramiz. Currently, his contribution is used almost everywhere Apache NiFi is used along with DataDog project integration.

Sharing three years of iOS team work to open-source

Andrey Moskvin, Senior Software Developer at Sigma Software, and his iOS team faced a need to facilitate the integration of their library:

“We’ve made a couple of our closed-sourced repos open-source.

Even though it was a long journey, we started this work to make the lives of library integrators easier.

The current Swift environment is not very friendly to the library. Swift has modular stability, but unfortunately does not offer a stable ABI, which makes it impossible to integrate different pre-built Swift binaries into one project.

If you are supplying a closed-sourced binary library there will be problems simply because each new Swift release (even minor one) easily breaks binary compatibility. Your library integrators suffer in that either they won’t be able to update to the latest and greatest Xcode, or they have to wait for you to update the library. This causes a lot of pain for both parties.

So, we moved all critical logic and decision making to the microservices (backend) in order to make the library just a simple representational layer of whatever was sent from the backend.

This allowed us to talk about open-sourcing with our clients and persuade them to see that the advantages of doing this outweigh the disadvantages.

In the security world, binaries are associated with a black box and are often hard to analyze for security threats. In the case of open-source it is easy to do, simply because there is no need to request access to the repos.

Both developers of the library and the integrators will benefit from this contribution. Developers are getting a simplified build process and no longer need to worry about the next release of a Swift compiler and Xcode. Only major breaking updates like going from Swift 4.0 to 5.0 will need source updates. Integrators no longer need to search for a specific binary built with exactly this version of Swift compiler. Also, they gain transparency of the code inside, the possibility to debug it, and to even make a PR if they find a defect or make an improvement. This is impossible in the case of binary distribution.”

Making fixes and improvements for GStreamer

Andriy Mykhaylyshyn, VR Project Architect at Sigma Software, and his team were working on an innovative VR social network project when they encountered some problems in GStreamer:

“We used the GStreamer applemedia plugin intensively in our project. My fellow engineers found defects in the plugin that kept interfering in our development process. As a result, we made a number of fixes and improvements to GStreamer applemedia, RTP, and osxaudio plugins. Most of the PRs we’ve contributed to were associated with memory leaks, performance improvements, and extended support of image formats. We also implemented and shared to the GStreamer open-source fork some improvements for better handling dropped packets in RTP, as well as the integration of an iOS echo cancellation system into osxaudio to enable video calls.

Though it was quite an effort, now all of the developers working on the project, as well as iOS GStreamer users, can find our repairs and enjoy trouble-free plugin functioning.”

Team Work Contribution to Open Source

Maintaining the Storybook Project

Alexey Pastukhov, Team Lead at Sigma Software, is part of the maintainers team of a Storybook project in which he helps developers switch from JavaScript to TypeScript:

“Storybook is interactive documentation that can be used to develop components in a vacuum and then demoed to a client. Currently, my role is to help developers switch from JavaScript to TypeScript. I review pull-requests, share tips, tricks, and knowledge about TS.
After I built a small plugin for the project and made it open-source, a maintainer called me and said that a feature of the plugin was to be implemented as part of Storybook in a few months. When they found out that I had experience with TypeScript, they invited me to join their team. As a big fan of OSS and Storybook, I decided to join and help.

It took several weeks to dive into documentation, code of conduct, and other aspects specific to the project. However, in general, I spend around four hours per week on this project.
What drives me is the thought that my work will improve Storybook integration with Angular or TypeScript + React, which will, in time, improve overall project maintainability.”

Conclusion: benefits of open-source contributing for software development companies

Open-source collaboration now aligns a significant part of the work done in software development companies with product houses. The benefits support both software engineers and the companies that encourage their employees to contribute to open-source. In particular, software engineers are exposed to new methods and ideas aside from their everyday work. They also have a chance to excel in trendy areas, as well as help progress new technology and the IT industry. Furthermore, Sigma’s work has become more visible to potential clients, allowing them the opportunity to assess the quality of our code and expertise. Further still, it allows us to promote our company culture of knowledge sharing and continuous education.

We, at Sigma Software, have long recognized the positive aspects of open-source collaboration, and both support and promote such activities amongst our engineers. Whether initiated internally, or inspired by our clients, open-source contributions from our experts represent a glimpse of our participation in the IT industry space.

Share article: