Contributing to Open Source Software

We love experimenting and trying new things at the Lifetime Value Company (LTV). Along this process, we usually leverage open-source software within different projects we have in the company. However, sometimes we find issues, missing features, and possible improvements that can be merged back into the open source software (OSS) so other developers can take advantage of them as well. 

In this post, we’ll share our experience as company developers working with open source software. First, let’s understand what open source software is and how we use it at LTV. Additionally, we’ll explore examples of how our company developers have contributed to the community and discuss potential risks associated with OSS.

What is Open Source Software?

 Open source software is code designed to be publicly accessible—anyone can see, modify, and distribute the code as they see fit.

 In a real example, let’s say we have been building a new feature to automate or do any task we need, and we want to share it with other developers. That’s when an open source community starts being created. It’s important to know that every software or tool in the OSS is not free, and  there are some terms and conditions of usage, important concepts, and some legal arguments to know about it. Take a look here to find a legal guide about OSS. 

When it talks about OSS not being free at all, it means the conditions of how to share it vary. Stipulations include keeping the authors’ names and redistributing with the same license. Also, if the license permits modification or redistribution for only non-commercial purposes, it’s not open source.

What is an open source license? 

An open-source license is a legally binding contract between the author of the software and the user. Software that’s publicly posted and available for free is not automatically open source. The license makes it officially open source. A lot of open-source software is free of charge, but that doesn’t mean that being free of charge is a requirement or guarantee of open-source software.

There are two categories of licenses: Copyleft and Permissive. Copyleft requires the user to apply the same license to their version of the product. This means that if the user modifies and shares the software, they have to maintain the open-source license. On the other hand, Permissive licenses do not have copyleft provisions, so the user is not required to keep their version of the product open source.

There are many types of licenses; here you will find a list of the common ones and some small descriptions for each one. 

Apache License

The Apache License is an open-source license by the Apache Software Foundation. Under the license, you can use, modify or distribute any Apache-licensed product.

Berkeley Software Distribution (BSD)

There are two types of BSD licenses:

• Modified BSD License (3-clause)
• Simplified BSD License, also called the FreeBSD License (2-clause)

Each BSD license gives permission to modify and distribute software code, source, or binary. However, you must retain a copy of the conditions, copyright notice, and disclaimer.

Common Development and Distribution License (CDDL)

The CDDL is an open-source license created by Sun Microsystems (acquired by Oracle). The current CDDL is version 2, and it’s a spin on the Mozilla Public License. It also replaced the Sun Public License, which came with free and open-source Sun products until 2004.

GNU General Public License (GPL)

The GPL is the most popular open-source license (WordPress plugins and themes must have this license). It’s a copyleft license, so any software that uses any GPL component has to be open source, even if just a tiny percentage of the code is in the modified code.

Massachusetts Institute of Technology (MIT) License

The MIT license is one of the most flexible open-source licenses out there, and it grants all the end-user rights you’d expect from an open-source license: copying, distributing, merging, modifying, etc. It’s mostly known for what it doesn’t include, specifically an advertising clause. Also, it allows the copyright owner’s name in promotional content.

Why is open source software important?

OSS has fueled some of the most important software used by millions of developers and companies. Also, it is important to remember that most of the software we use to develop is OSS. 

At LTV, we are concerned about this and the importance of OSS and this is why we want to share knowledge and making aware everyone about OSS, this is part of our culture and our core value which is ‘Teach Each Other To Fish’ (Here in case you want to see our core values). OSS is the reason why technology has grown like foam for the past few decades.

Also, it is important to mention how most of the frameworks developers used today, are fueled by OSS, including Rails, Golang, Angular, React, EmberJS, and libraries in software from the most diverse areas, these have been used by thousands of developers. From the Machine Learning fields, we also have some Pytorch, TensorFlow, OpenCV, YOLOv7, and many more. 

Another important area where OSS projects are, is in the DevOps culture; such as Docker, Kubernetes, Terraform, and many more. All these tools are now widely used and those are related to having a good architectural application that is used by millions of users.

Open source software is more than just a set of code that anyone can use, modify, and distribute. It represents a different way of thinking about software development, one that is built on collaboration, transparency, and innovation. Below, we’ll explore some creative points of view on open-source software that highlights its unique benefits and potential.

Open-source software is a social movement

At its core, open-source software is about people coming together to solve problems and create something of value. It represents a social movement that is driven by a shared vision of technology that is accessible, equitable, and empowering. By embracing open-source software, individuals and organizations can participate in this movement and contribute to a global community of developers, users, and advocates.

Open-source software has the potential to be a powerful tool for social change. By making technology more accessible and equitable, open-source software can help to bridge the digital divide and promote greater participation in the digital economy. Additionally, by fostering collaboration and innovation, open-source software can help to create solutions to some of the world’s most pressing social and environmental challenges.

Open-source software is a platform for experimentation

One of the key benefits of open-source software is that it enables developers to experiment with new ideas and approaches without fear of failure. Because the code is openly available, developers can try out new features and approaches, receive feedback from the community, and iterate on their work. This platform for experimentation can lead to innovative new technologies and approaches that might not be possible in a more closed, proprietary environment.

Open-source software is a source of inspiration

The collaborative and creative nature of open-source software can be a source of inspiration for developers, designers, and entrepreneurs alike. By studying open-source projects and participating in open-source communities, individuals can learn from the successes and failures of others, and apply those lessons to their own work. Additionally, open-source software can inspire new ideas and approaches that might not have been considered otherwise.

Open-source software is a way to give back

For many developers, contributing to open-source software is a way to give back to the community and support the greater good. By sharing their code and expertise, developers can help to improve the quality and reliability of open-source projects and enable others to build on their work. Additionally, by participating in open-source communities, developers can build valuable connections and relationships with like-minded individuals and organizations.

How do we start contributing to Open Source Software? The LTV experience. 

Contributing to OSS is a journey with multiple steps. It begins by identifying a need that an existing (or non-existing) library or project has. Next, it involves defining what needs to be done to fulfill this need. Afterward, it is important to validate this need with other developers in the community and the maintainers of the library, in order to understand why it hasn’t been implemented or addressed yet. Finally, it is time to discuss possible approaches to solve the need. It may be a long road, but one that brings immense satisfaction upon completion.

At LTV, contributing to OSS has been key for the success of the career path of many of the engineers working here; There is no one or two, but multiple people in the company who have contributed and continue contributing to OSS. 

We shared some questions with some LTV employees that already contributed to OSS, here you will see their thoughts/responses. Each bullet is a response from a different person. 

In which libraries/projects have you worked with OSS?

• Rack, Resque (Patrick Tulskie, VP of Engineering)
• Zendesk Ruby Gem (Kevin Pedroza, Engineer 1)
• I contributed to an AVRO codec for Golang, adding support for unmarshaling union values to their logical type instead of their primitive type. https://github.com/hamba/avro/pull/71 (José García, Associate Director of Engineering 1)
• I worked on the go-gorm/bigquery project (Nazareth Roman, Engineer 3)

What are some of the pitfalls you’ve found while doing OSS?

• Getting stuff merged in/reviewed by the project’s maintainers can be difficult. I once had a PR get merged 2 years later for a feature I added. By that time we’d stopped using the library. (Patrick Tulskie, VP of Engineering)
• Trying to merge the change to main, it is difficult to get in touch with the maintainer even to get reviews. (Kevin Pedroza, Engineer 1)
• Trying to understand the whole project you’re contributing could be challenging, I would suggest for anyone wanting to contribute to open source projects to focus on a specific and small area instead. (José García, Associate Director of Engineering 1)
• I didn’t find anything really hard in that contribution, however, I would have loved that the project had unit tests for the piece of code that I was modifying, which it didn’t, so I had to test the cases on my own. (Nazareth Roman, Engineer 3)

Did you find hard to contribute in OSS?

• Not really. I just makes sure I look around and assess what is going on in the repo before I start trying to make changes or additions. (Patrick Tulskie, VP of Engineering)
• It is not really hard, you just need to find any issue or add a feature you would like to have or need in the library .(Kevin Pedroza, Engineer 1)
• Not really, it is just a matter of finding a good opportunity that benefits the company. (José García, Associate Director of Engineering 1)
• This contribution was not hard since Go is usually well documented and many projects follow best practices. (Nazareth Roman, Engineer 3)

What would you do differently to lower the entry barrier for contribution in OSS projects?

• Have a contribution guide in the readme for the project. Set expectations for contributors and steer them towards that when they submit things that don’t meet your expectations. (Patrick Tulskie, VP of Engineering)
• I would enhance people to know OSS; sometimes whatever repo you find, you will only care about how to use and how to install it. But we are not concerned about how to collaborate with them, even if there is the info on the readme. So, we have to promote that culture of collaboration. (Kevin Pedroza, Engineer 1)
• As I said before, focusing on specific and small areas of a project. A simple and small contribution are usually the best ones and the quickest ones to be released. (José García, Associate Director of Engineering 1)
• I wouldn’t do anything differently in specific because in my case this was a very clear and straightforward change; however, since we needed this change to be applied soon, I didn’t consider writing unit tests for the change because it had to be started from scratch in the project. I would like to open a new PR that introduces unit testing for many of the pieces of code that didn’t have. (Nazareth Roman, Engineer 3)

In general terms, what insights could you share such as learnings, experiences or findings when contributed to OSS?

• Don’t take things personally. When you submit something, you’re basically tapping a random stranger on the shoulder or shouting into a crowd. It may be necessary to reach out to maintainers outside of github or bump your request a few times. OSS maintainers are often doing this work for free and their work/lives will usually come first. (Patrick Tulskie, VP of Engineering)
• I think the most important one would be filling up our expectations and motivation, once we know about OSS and we want to collaborate, that thirst is not filled up till the PR is merged. Then, I would say, OSS is a new world and you understand the code differently cause in the end you are coding to optimize others’ work with your work, so that experience is very nutritious. (Kevin Pedroza, Engineer 1)
• It’s a great and rewarding experience. (José García, Associate Director of Engineering 1)
• I found that it is important to keep eyes open and be aware of opportunities that can really help my team and help outside users potentially. In my case, I think it was a straightforward contribution because I made sure to keep it as concrete as possible, trying to solve a single problem and focusing on not introducing breaking changes. I think those were some of the reasons why my PR was accepted without any problem. Also, as I mentioned before, Golang provides vast documentation about best practices and abstractions so that many pieces of code are compatible with each other.

Something that was useful to me was to fork the repository and create an initial Pull Request in my own fork so that my teammates were able to give it a first round of reviews and provide me with feedback before submitting the PR to the project and of course deeply test it locally. (Nazareth Roman, Engineer 3)

How did the contribution help LTV CO?

• In the case of Rack, I patched a bug that could be leveraged for cache poisoning and XSS. I patched it for us so that we were protected and submitted the fix upstream. That one took a while to get merged in, but we were protected in the meantime. In the case of resque, I actually offered to help the maintainers out with shipping new releases since we are heavy users of resque. I now help get new releases out the door and review PRs from other people. (Patrick Tulskie, VP of Engineering)
• When adding the new feature to Zendesk Gem, we were running on the deadline from Zendesk. Since the old would get deprecated and would start reducing the number of requests, in LTV we have a huge amount of requests from Customer Service. So, keeping this up to date would increase the Customer Service Rate and, most importantly, our culture. (Kevin Pedroza, Engineer 1)
• We were able to create data pipelines that can handle optional timestamp fields and decoded them into dynamic (unknown) types. (José García, Associate Director of Engineering 1)
• Background: I’m part of the Data Engineering team and during the development of one of our data pipelines, we came across the need of implementing an extractor that uses the Gorm BigQuery driver and we required the use of scopes to get data from a view that is being populated by a Google Sheet. The current implementation of the driver didn’t handle the scopes option.

Feature: Being able to authenticate the bigquery client by passing OAuth2 scopes received in the uri as an optional value.

Pull Request: https://github.com/go-gorm/bigquery/pull/1 (Nazareth Roman, Engineer 3)

Some risks in OSS

As you can see, the journey at LTV collaborating with OSS has been useful and very productive, but as you would imagine, there are some risks involved when we talk about OSS.Below is a non-exhaustive list of some of the common issues.

• Compatibility risks

  • Open Source software may not always be compatible with other software, especially proprietary software. This can cause compatibility issues that may require additional resources to resolve.

• Abandonment by maintainers

  • We have faced issues when for example, we want to collaborate with fixing issues or adding a new feature and in some cases, the maintainers do not collaborate on reviewing PRs or merging PRs that are ready. It could be annoying and critical when there is a deadline to conclude any task related to the feature or fix. 

• Toxic behavior

  • Toxic behavior within the Open Source community is an unfortunate issue that can hinder collaboration and progress. Instances of such behavior, although not representative of the community as a whole, do occur and can have negative consequences.

One form of toxicity commonly observed is harsh and disrespectful communication. This includes personal attacks, belittling remarks, and dismissive attitudes towards others’s ideas or contributions. Such behavior not only discourages newcomers from participating but also creates a hostile environment that inhibits open dialogue and constructive feedback.

• Trust OSS

It sounds weird to see the “Trust on OSS” as a risk. But, there are some cases where we trust others to provide us with more layers of abstractions so we can focus on delivering value. But what happens when the trust chain is broken?

•  Leftpad was an example of this in 2016. Used by high-profile projects like React, Node, and Babel listed them as dependencies. It was taken out from NPM due to a developer being in conflict with a company due to a module naming. The developer was angry that NPM removed the conflicting package, and he removed 250 more packages from NPM. This caused multiple projects depending on this dependency to break. Imagine not being able to deploy because an open-source maintainer decided to remove his package.

• Another case that is most recent is the breaking news about “Color” and “Fake”’ npm packages that were sabotaged.If you want to know more about it, you can check it out here. 

•  Log4j Forever Changed What (Some) Cyber Pros Think About OSS, In late 2021, the Apache Software Foundation disclosed a vulnerability that set off a panic across the global tech industry. The bug, known as Log4Shell, was found in the ubiquitous open-source logging library Log4j, and it exposed a huge swath of applications and services. 

Recommendations

As a company passionate about Open Source Software (OSS), we believe in the power of collaborative contributions. If you’re interested in contributing to OSS projects, we have some recommendations to make your experience rewarding and impactful:

• Find projects aligned with your expertise and values
  •  Look for projects that align with your skills and align with your values or industry focus. This ensures that your contributions are meaningful and contribute to areas you are genuinely interested in.
• Start with smaller tasks and build your way up
  •  Begin by tackling smaller, manageable tasks to gain familiarity with the project’s codebase, workflow, and community dynamics. This approach allows you to build confidence, learn from experienced contributors, and make a positive impact from the start.
• Respect the project’s guidelines and processes
  •  Follow the project’s guidelines, including coding conventions, documentation standards, and version control practices. Adhering to these guidelines ensures consistency and facilitates the review and acceptance of your contributions.
• Contribute quality code and documentation
  •  Prioritize quality in your contributions. Write clean, well-documented code that adheres to best practices. Ensure your contributions include comprehensive documentation, including clear instructions and examples that make it easier for others to understand and use your work.
• Test and validate your changes
  •  Thoroughly test your changes to ensure they function as intended and do not introduce new issues. Follow the project’s testing guidelines and consider different scenarios, edge cases, and compatibility across platforms. Reliable contributions are valuable to the project and its users.

Conclusion

Contributing to open source software can be a fulfilling and rewarding experience for developers at any level. By participating in open source projects, developers have the opportunity to collaborate with others, learn from experienced programmers, build their skills, and make meaningful contributions to the technology industry.

Moreover, contributing to open source software is a great way to give back to the community and make a positive impact on the world. Open source software has the potential to solve important problems and provide free, accessible solutions for people all over the globe. At LTV, we love giving back to the community and positively impacting the world.

If you are interested in contributing to open source software, there are many resources available to help you get started, including online tutorials, community forums, and mentorship programs. By taking advantage of these resources and working with other developers, you can gain valuable experience and make a difference in the world of technology.