BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Why Developers and Staff+ Engineers Should Get Involved in Open-Source Collaborative Development

Why Developers and Staff+ Engineers Should Get Involved in Open-Source Collaborative Development

Key Takeaways

  • Today’s software development includes extensive use of open-source libraries, APIs, and other components. Most companies use over 70% open source in their infrastructure, products, and services. It is important for modern software developers, especially in staff+ roles, to know how to work with open source.
  • There are many benefits to a software developer getting involved in open source with code and other contributions. The benefits extend to mentorship from the open-source project, improving leadership and communication skills, and achieving status as a key developer in the project.
  • Some simple steps developers can take to get involved include attending an open-source meetup or event or joining a project mailing list.
  • One of developers’ biggest challenges is getting their companies’ support to do open-source work. As the benefits to companies are more long-term and indirect, staff+ leaders can help their companies understand how it benefits them and allow time to get involved.
  • With the extensive use of open source, staff+ leaders can help a company understand how to maintain open-source components critical to the company’s success by getting involved in the open-source project.

The Role Open Source Plays

Software development used to be mostly inside a company or an organization and had very little external collaboration. Collaborating with partners and others happened only if a contractual relationship existed. Developers were rarely able to share or talk about the work they were doing. You needed to join a company and work under their direction to do coding. There was a lot of work duplication with very little leverage of previous work across the industry. All this changed with the beginning of open-source software in the 1990s.

Over the last 30 years, the world has become connected and digital. More businesses and organizations are built on software, especially open-source software. Industry studies show that over 90% of companies use open source, and 60-90% of our software stacks are open source. There is not a single day that goes by when we do not use open source.

Open source is also how we do modern software development, stitching together downloaded open-source libraries, frameworks, and other code to create new applications or functionality. This is why every developer and senior staff+ roles need to know what open source is and how it works.

How the Staff+ Role Looks in Open-Source Projects

Many of the staff+ roles in technology companies, such as principal engineer or distinguished engineer, can work in open source. My team at Amazon has three principal engineers who tackle company-wide and exciting challenges in open-source strategy. They mentor, influence, and greatly impact developers across the organization. Many have no interest in people management but want to have a broad influence on the company and solve big problems.

Some staff+ roles in technology can run small teams of experts who are the go-to team for specific technology topics. Staff+ roles in my previous company were almost always Individual Contributor (IC) roles. But now and then, you saw staff+ roles with small teams. That allows the staff+ leader to combine their work as a technical expert with a people management role. The small teams were usually experts who were the go-tos for that subject matter and allowed the IC to scale their knowledge across the company.

My role as Engineering Fellow at Comcast was such a role. I could run a small team and still have time for individual contributor work, such as writing papers and speaking at conferences. This was possible because the team I ran, the OSPO or Open-Source Program Office, was a small expert group advising developers and business owners across the company. It allowed me to set aside time to do individual work such as strategy, writing a paper, or speaking at an event.

By being flexible on being an IC only, one can combine management and IC roles and build more flexibility into a career. Even as a senior IC, a staff+ engineer needs to exercise people skills such as mentoring, communicating ideas, negotiating, and influencing.

Challenges Faced by Staff+ Developers When Contributing to Open Source

The number one challenge is making or finding time to contribute to open source. Not many organizations will give you the time to contribute to an open-source project not associated with your daytime job. You may need to find time in the evenings and on weekends. Women, in particular, often have primary responsibilities as caregivers and find it difficult to find time.

You need to convince your organization why it should allow you or your teams to spend a portion of your time contributing back to open source. The benefits to an organization are often long-term and include soft benefits like trust and the ability to influence a project. Because organizations are all about hard, quantifiable bottom-line impact, managers are reluctant to allow time for teams to send back patches or volunteer time.

Senior technologists, such as staff+ roles, have the organization’s trust and can show how the time invested can help sustain the project, especially if it is a critical dependency for the company’s roadmap. A principal engineer who worked closely with me often knew the payoff of working closely with a project. They advised the business on how our developers needed to create a relationship with the open-source community project to allow us to support our customers. This was very helpful when we were building more expertise in the company on cloud native open-source projects. Staff+ leaders can lend their credibility and knowledge to help managers invest in open-source projects critical to the organization.

Senior technologists or staff+ leaders can also speak at open-source events and be visible in communities on the company’s involvement. One of the difficult discussions inside a company is whether a company-developed technology should be open sourced. Companies value patenting new ideas and building their patent portfolios. When they release their technology to open source, the fear is that they enable competitors and give away their Intellectual Property. However, when you closely examine the technology, you realize not everything needs to be kept inside. Open Sourcing may allow the industry to rally around a standard way of doing things you create. It may allow you to create a more extensible project with new use cases or support for new hardware. Senior technologists, especially in that specific domain, can play a key role in helping an organization think through why or why not.

Some open-source communities may not be very welcoming and hard to get involved in. Often, this is because they have little time to dedicate to hand holding new entrants. By watching the mailing list to see where the community needs help, you can earn their trust by helping with their needs. Making yourself useful is the best way to break into tough communities. Sometimes, it may not work out, and you need to move on. This will take persistence to earn your way in with your contributions of time and code.

Open-source projects and code can be complex and have no documentation or commit messages. And it can be difficult to understand and contribute to. If you persist and make the time, it can be rewarding.

My Journey in Open Source

I started many years ago as a developer and was always curious about other roles in technology. This led me to explore product management, marketing, and strategy and go broad in my roles.

By going broad rather than deep, I was able to participate in technology strategy more effectively and understand the different dimensions of how we innovate and take products and technologies to market. My involvement in open source that started in the late 1990s led to many roles in companies from managing open-source-based products to running open-source offices for Fortune 50 companies.

The roles were never dull as open source crosses legal, technical, and social dimensions and let me fully explore all dimensions of creating new technology. I have been fortunate to meet great people and participate in some great communities. Because open source works across organization boundaries, I often worked with people in different companies and non-profit foundations. I got to travel all over the world for conferences and meetings. It has been a rewarding and exciting journey.

Benefits to Software Engineers from Open-Source Contributions

Knowing the sociotechnical ways open source works has so many career benefits. People who contribute learn to communicate their work, learn to collaborate with people worldwide, and know how to navigate the open-source project and community processes. These skills are especially important at the Staff+ level, where you must develop your influencing and communications skills.

There is also a sense of purpose in ensuring a project survives and serves users especially if it is an area that you are passionate about.

Many well-known contributors and maintainers are in demand by companies who depend on the project they are experts in. Maintainers can continue to do their work even while working in a company.

My open-source work has opened many doors for me. The chance to speak at worldwide conferences, the opportunity to meet people from many companies, and be a leader at an organization like the Linux Foundation has opened doors to strategic roles at companies like Comcast and Amazon.

I am very grateful for discovering and working in open source and for the great global community of people that I am a part of.

Organizational Benefits from Open Source

Organizations are all consuming open source and need to employ people who understand how to work with open-source software and communities. Having experts in open source allows organizations to manage their dependencies on open-source projects. With open source, it is as if organizations have external development teams that they need to work closely with.

By participating in open-source communities and projects, companies are able to also support projects that are badly in need of resources or money to keep going. As organizations, we use open source extensively. Open-source projects are often volunteer-run, and struggle to keep the project alive. By contributing to the finances or the work needed, the company can sustain projects, especially the ones that the company may depend on.

Organizations that support their developers doing open source are more successful in recruiting, retaining, and growing their technical talent. They can showcase their work in open source and show that they are doing innovative work.

Lastly, open source helps companies innovate faster and focus their small and dedicated teams on what they are good at while depending on open source for undifferentiated areas.

How Can People Use Their Talents in Open Source

The barrier to getting involved in an open-source project or community is low. You do not have to sign a contract or join a company to do it. You can find a favorite language or project on GitHub or GitLab, join the mailing list, and find ways to help the project.

Projects often list what they need in terms of help and first-timer issues. You can fix a bug, file a problem, help with documentation or translation, or even evangelize the project. Most often, projects need help reviewing issues submitted by users, deciding how to solve those issues, or reviewing pull requests submitted by developers for acceptance.

Maintainers of projects want you to help and not create more work for them. In open-source, we call it chopping wood and fetching water for tasks that need help. These are generally basic, managing the project—keeping documentation up-to-date, answering questions, etc. Things that may not be glamorous but are very needed.

According to Tidelift’s report on open-source project maintainers, 41% of open source projects have only one maintainer and are very much in need of help. Often, these projects are used by thousands of developers around the world. These under-resourced projects could use additional hands to sustain the project for users worldwide.

The work done in open source can add to your promotion or performance story. Companies that use open source recognize developers’ work in open source. Earning status as a committer to a project (one who has the right to accept code into the project) or into a leadership role is often recognized as an achievement inside the company.

My Advice to Developers and Staff+ Roles for Active Engagement

Go to open-source events like the Linux Foundation’s Open-Source Summit or All Things Open in Raleigh. Get to know the community and how to get involved. Often, there are sessions for first-time attendees and 101 sessions that help you get involved. The hallway track at events is a great way to meet open-source experts and understand how they got started.

See if your organization has an open-source office (OSPO) and if you can get involved in the office and its efforts. Check out a project that you use and its community to see how you can contribute and support it.

Staff+ roles like Principal Engineers and Fellows are often the best to get involved as advisors and strategists to the open-source office. They can often bring the arguments to the table on why something should be open sourced by the company. And to also advise the business on the investment to be made to staff and support a project. In all the organizations I have run an OSPO, partnership with senior technologists was key to the right strategy and investment in open source.

Start small and continue, as it will be a rewarding experience that will help your career and deliver personal satisfaction. One of the best guides I have seen to contribute is the open-source guides on how to contribute that GitHub has created.

About the Author

Rate this Article

Adoption
Style

BT