11

Open Source and the Talent Ecosystem

As I’ve mentioned several times in this book, open source is a “scratch-your-own-itch” model, meaning individuals get involved with projects that interest them, solve problems they have, and contribute in beneficial ways. The benefit to the individual can be in several tangible ways and usually relates to an acute need, such as a framework for building a software application, tools for working with a device, or full applications to replace commercial software. But many also look at open source as an enabler for their career, where their contributions and peer recognition can be a way to showcase their skills to potential employers.

The investments we’ve seen by companies in open source in recent years are a testament to the importance of open source for them to better execute as a company, which we looked at in Chapter 10, Commercialization of Open Source. This chapter digs into one major aspect of that execution, which is attracting and retaining great talent. Developers today are keen to make sure they can contribute to open source as part of their job; for them, it’s, in a way, an “insurance policy” in the sense that they are building a portfolio to make them more relevant in the job market. Employers naturally worry about this; if an employer’s investment in an employee effectively makes it easier to leave, isn’t that the wrong approach? It’s not; we’ve seen in many research reports and surveys that employees value company culture and interesting work the most, so if a company continues to invest in that, they likely will better retain talent. Participating in open source fits into that value proposition for developers, so it’s really important that employers recognize that versus trying to prevent it.

My passion for open source is because of not only the collaboration and innovation it drives, but because it has been an enabler in my career, which as of this writing, spans nearly 25 years of using, contributing to, and leading open source projects. I could trace it back even further, to the early 1990s, when, in computer magazines, they would have programs written in BASIC that you could type into your computer. BASIC interpreters weren’t standardized, and the programs were often written in BASIC for Apple II or Commodore computers; my family had a TI/99-4A, so as I typed in the BASIC code, I would need to do the translation to the nuances of the BASIC dialect for the computer I had. If only we had a platform such as GitHub or GitLab back then; I probably would have published the code for others as sometimes it was quite tricky to get it all right.

In this chapter, you will see how you, as an open source project contributor or maintainer, could leverage your work to grow your career. Additionally, we will look at how organizations can find new talent among the contributors to open source projects that they use. Finally, we will build on Chapter 4, Aligning the Business Value of Open Source for Your Employer where we spoke about how organizations can recognize their own employees who contribute to open source, by seeing how organizations can support career growth for contributors. The topics we will cover include the following:

• Open source as your portfolio
• Finding talent through open source
• Recognizing employee contributions to open source

Let’s start by looking at how open source can be a portfolio for a developer or open source enthusiast.

Open source as your portfolio

The concept of a “portfolio” is often associated with artists and photographers, where it is used as a tool to evaluate the skills and specialties of a person by seeing what they’ve done in the past. In software development, historically, there hasn’t been this same tool. You most often see employers use coding challenges in addition to credentials from a candidate’s resume or CV to determine the skills and capabilities of a software developer. Sometimes the strategy works, and sometimes it doesn’t.

Back in the 1980s and 1990s, and into the early 2000s, most software developers were considered “full-stack developers,” meaning they had competence in all areas of application development, from frontend design to backend coding, database management, and server installation and configuration. Software development became more specialized in the 2010s, with developers often more skilled in specific areas such as database management, frontend development, or specific technologies, such as Python, Java, or Node.js. This proliferation has made identifying talent more challenging, both from the perspective of finding developers with a particular skill as well as for potential employees to appropriately share their competence.

With open source, all the code a developer creates is made available under a license that allows it to be viewed by all, so potential employees can share links to code repositories they contribute to. Additionally, employers looking for specific skills can view the discussions and code collaboration of a community and find the developers who know the most – and then those employers can proactively reach out to them.

This shift has made an impact on software developer careers globally – even for me! Let me share my story.

My career story

I went to Kent State University and majored in computer science, learning several languages, including C, Perl, MATLAB, Lisp, Bash scripting, and PHP. PHP was especially interesting to me; we used it in a Capstone project where we built a website for a local county government. What impressed me the most about PHP at the time was how little code was required to do something useful. I even created a simple weblog site for my honeymoon.

My broad computer science education, and my growing PHP skills, were helpful in landing my first job as a software developer for a local financial services company back in 2001. If you were around in 2001, you know it was the high point of the first dot-com bubble bursting. Combined with the general economic downturn after the 9/11 attacks in the United States, jobs were difficult to come by.

At that first job, my primary role was development in FoxPro and Visual FoxPro as that was what the applications they used were developed in (a fairly common case for small businesses at that time). But they had an interest in improving how they engaged their customers and wanted to start offering access to accounts via the web. My PHP skills were immediately useful here, and in my 7 years, I built out numerous web frontends to the internal systems they had, which helped them better serve their customers and reduce internal costs.

Getting more involved in the PHP community

As I was getting more into PHP, I started getting more and more involved in the community. At first, I submitted a few bugs to the PHP project, which were fixed over time. Then I started attending PHP conferences, the first being php|works 2003 in Toronto; another PHP conference after in Vancouver; and the next summer, O’Reilly’s Open Source Convention (OSCON). It was quite an experience seeing the open source community up close and personal, hearing Rasmus Lerdorf himself speak, learning about new trends in PHP development, and meeting some amazing developers building applications, libraries, and tools in PHP. My biggest takeaway, outside of the technical skills and tips, was the strength of communities and how everyone had a way they could participate. I remember talking with a speaker about AJAX (which stands for Asynchronous JavaScript and XML) and at the time AJAX was an emerging technology topic. While I learned a lot from the speaker’s experience, the speaker also valued what I had done with AJAX. It was quite cool that both of us were teachers and pupils in the same conversation.

I kept doing more and more with PHP, including using some of the newer features of PHP 5 and starting to refactor the web applications I was building to use the up-and-coming Zend Framework (which now is the Laminas project). One thing that stuck out to me was the experience of developing PHP on Windows. While it worked, it took a bit to get it all set up correctly. There were some efforts out there to build installer packages for PHP, but most were either clunky or included the Apache Web Server and MySQL. While that was helpful, the install wasn’t very much like how Windows apps were installed.

I contacted the main developer for the current PHP Windows installer and shared that I was interested in rebuilding the installer using a new open source project from Microsoft called Wix. Wix was one of the first open source projects that came out of Microsoft and was designed to enable building native MSI-based installers for applications using XML. I was interested in playing with Wix, so this seemed like a great opportunity to do so!

It took a few months, as while doing this my wife and I were expecting our first child, but shortly after she was born, I put out the first beta release of the installer. Figure 11.1 is my brave first post to the php.internals mailing list announcing the installer.

Figure 11.1 – Release announcement for the PHP Windows installer for PHP 5.2 (https://news-web.php.net/php.internals/24929)

I got tons of feedback from those on the php.internals mailing list over the next few weeks and released an updated version about a month later. It was an exhilarating experience – not just writing code with feedback from the community, but getting feedback from core developers of PHP at the time. Folks such as Ilia Alshanetsky, Wez Furlong, Steph Fox, and others chimed in to give feedback. It was like the moment you met a celebrity – it was surreal. But while they were amazing engineers with tons of experience, they were just normal software developers like me, which at the time I didn’t expect, but looking back on, it aligns with many of the people I’ve met in open source.

What was a surreal moment was getting an email from Kanwaljeet Singla, who was a software engineer at Microsoft. Microsoft was wanting to improve its support for PHP on Windows, especially with Windows Server and their web server known as Internet Information Services (IIS). He had some feedback on how IIS worked and wanted to see if I could help improve the installer for a better experience on Windows. In my head, I thought “Microsoft wants me to write code to help them? Sign me up!” Again, probably one of those celebrity moments. We worked together for several weeks, and they provided a free copy of Windows Server 2003 for testing. We got everything sorted out and made part of a PHP 5.2 point release later that year. And as a token of gratitude, they sent me a Microsoft Zune MP3 player.

PHP community work opens new doors

As I was effectively a PHP maintainer at that point, I was getting more attention in the PHP community. I found out I made a card deck of key people in PHP that Zend put out in 2007, and had several job offers from employers looking for PHP talent. The open source as your portfolio concept was truly working for me.

In late 2007, I took a job as a software engineer at SugarCRM, then one of the biggest open source PHP applications in existence. What helped me land that opportunity was not only the work I did in the PHP community but the people I met. One in particular, Travis Swicegood, was working at SugarCRM at the time and got me connected to them. It was also my first time working as a remote employee, which was a big shift for me but one that, as of this writing, I’ve loved (going on 16 years!). I had a great opportunity to work with amazing engineers there: Majed Itani, Roger Smith, Collin Lee, Andy Wu, Jacob Taylor, and others.

Over time at SugarCRM, my interest in engaging the community grew, and I took the leap in late 2008 and applied to speak at conferences. I had several rejections, being a new speaker, but one took a chance on me: DC PHP Conference. It was a bit nerve-wracking as I was no longer as anonymous in the community, but now in front of people as an expert. I’ll admit, the talk wasn’t very good. But I got better over time, and today I have many keynotes under my belt and hundreds of talks done globally.

After a few years at SugarCRM, and being invited multiple times to speak at conferences throughout the United States, as well as Europe, I was promoted to community manager. This meant I was in charge of leading and growing the SugarCRM community, as well as being an ambassador for SugarCRM in the tech and open source world.

This opened many doors for me. I was invited to serve on the board of OW2 (ow2.org), as well as to be the secretary and eventually the president of the OpenSocial Foundation (now defunct). Speaking globally, I was invited to more conferences, meeting and learning from people big in open source – many I’m still connected to today.

One memory I have of that period was a dinner I was invited to by Larry Augustin, then CEO at SugarCRM, after his keynote at LinuxTag 2010 in Berlin. At that dinner was Chris Dibona and Dirk Hohndel. Chris, at that time, led open source at Google (and still does to this day) and Dirk, at the time, led open source at Intel and the Meebo project (later, he led open source at VMware and Verizon, as well as serving as an advisor to the Linux Foundation). Remember that celebrity moment I had when I first released the PHP Windows Installer? This was the same, times 100! Chris checked out my new Android phone, an HTC Incredible 2, as Android was quite new and he hadn’t seen that phone yet. They all shared stories of their years in open source and I sat there almost completely frozen – half petrified and half taking in the moment. I look back and feel embarrassed about that dinner (Larry, Chris, and Dirk – if you read this and remember that dinner, apologies again!).

Community management grows into leadership

In my later time at SugarCRM, I helped jumpstart our software partners program, which gave me some great experience in connecting business value back to open source. I was able to do that again in my next role at Bitnami, where Daniel Lopez Ridruejo and Erica Brescia trusted me to launch a similar program with the growing cloud enablement business. Both experiences weren’t perfect; I hit a number of bumps in the road but also has some nice successes in helping both companies drive more revenue. It was valuable for me as it made me realize what drives collaborative work – mutual benefit.

In 2015, Jim Zemlin connected with me about roles in the growing Linux Foundation. The opportunity for me was a dream come true – the opportunity to work in driving open source across multiple companies and industries, with the ability to focus on making open source projects successful. Late in 2015, an opportunity opened up to lead the newly launched ODPi project and the Open Mainframe Project. In my time at the Linux Foundation, I’ve been able to connect my experience working as a developer, maintainer, and community manager in open source with the business leadership I learned at SugarCRM and Bitnami to help multiple open source foundations and projects within flourish, including the Academy Software Foundation, LF Energy, LF AI & Data, and many more.

While I hope you have found my career story up to this point interesting, you might be thinking “so what does this all mean, John?”. Well, let’s look at how to apply what I’ve experienced to your career.

Growing your career in open source

Everyone’s careers are winding roads, and rarely – if ever – predictable. My career certainly has been – going from being a computer scientist to an open source leader and expert certainly isn’t a career path my high school’s guidance counselor even knew existed. But what it says is that your career path is one part opportunistic and one part luck. For me, it was opportunistic that I was able to take over the PHP Windows installer, and pure luck that I met so many open source leaders. Both helped catapult me to the next phase of my career.

As I look back at my career journey, there are a few patterns that stick out that I think will be helpful to you as you grow your career in open source. Let’s look at them now.

Showcase your work

We live in an age where our digital footprint is in effect our identity, and showcasing that broadly and accurately is crucial. I heard someone say once that “if you don’t define yourself in the market, someone else will do it for you.” Being successful means owning your work and accomplishments.

There are a few key platforms to pay attention to in relation to open source:

• GitHub or GitLab, both of which are presently looked at as the primary portfolios for open source work. Here, you want to make sure the open source projects you maintain look well put together: working code, solid README files, clean structure – all the best practices we outlined in earlier chapters. While employers look at competence with technologies as a key for hiring, they also highly value code that is readable, easy to understand, and documented, as code bases for companies are maintained by teams that need to work together. GitHub and GitLab are also both good at showing other projects you might have contributed to.
• LinkedIn, which again is a de facto platform in the technology world. Here, you want to focus on your employment history, giving details of the roles and responsibilities. Additionally, call out the open source work you’ve done; call out being a contributor or maintainer to a project and describe what you’ve done. Provide links to blog posts and conference presentations you’ve created, which show both expertise in the technology but also your ability to talk about technology such that others can understand it – a really important skill to employers.
• Twitter, Mastodon, and Facebook, all of which are currently popular social platforms that employers will look through to get a sense of who you are as a person. Companies look for cultural fits as much as they do technical skills. I personally am not a big user of those platforms, or any other social media, but if you are, ensure that you don’t have embarrassing pictures or posts, or ones that are derogatory or attack others.

Many developers have personal websites if they aren’t into using the platforms above, and if you go down that path the same general guidelines apply. You probably want to also search for your name in search engines and see what comes up. If you use the platforms outlined previously, likely those will get the job done, but if it’s a personal website you probably will need to pay attention to the results and work to get your website toward the top through Search Engine Optimization (SEO) techniques.

For me, I focus on maintaining a LinkedIn profile for showcasing my professional career, as well as using my GitHub profile to showcase all the projects I’ve worked on over time. For me, as an open source expert, it showcases both my professional dimension as well as my experience working on open source projects by showcasing all the ones I’ve made some sort of contribution toward. Additionally, I maintain a few small open source projects around DCO signoffs and managing ecosystem landscapes, which show others good practices in presenting smaller projects appropriately.

With your portfolio in place, you now have a great resource that showcases your work. Even with a strong portfolio, it’s hard to get that “in” or opportunity to showcase yourself. This is where, sometimes, you have to look to solve the problem others look past. Let’s learn more about that now.

Look for opportunities people look past

The PHP Windows installer was an afterthought for the PHP community; most of the primary maintainers of PHP were Linux users and saw Linux as the best platform for deploying web applications. Combined with the disdain the general open source developer had for Microsoft at the time, it made the opportunity of the PHP Windows installer a great one.

The beauty of open source is the wide breadth of projects and problems to solve. And in those projects, every one of them needs help in one way or another. Finding your way into the project, perhaps by tackling one of those “good first issue” bugs that the primary developers have eschewed, is a great way to make inroads without the stress of needing to compete with others and getting lost in that mess.

With the PHP Windows installer, the opportunity was driven by the work I was able to do myself. But as I grew in my career, the opportunities became ones where I had to influence others. This is where I learned the next pattern – being an enabler to be a leader.

Be an enabler to be a leader

One big criticism of the career path for software developers is that it often leads to management – a skill no software engineer is at all prepared or trained to do along the way. Criticism aside, growing one’s career means learning new things, and often you need to go outside of your immediate role to learn them. For me, the transition from software developer to community manager – effectively from being an individual contributor to being a leader – was a challenging one. I had to re-learn a bunch of things along the way to be successful, such as how to enable and support others to help me achieve my goals, how to prioritize and shift focus, and even how to see down the road of opportunities ahead. I had to stumble and fail – a lot – and I had to learn to be okay with that. As an individual contributor, you often see your value as the work you can do yourself. But as a leader, your value is the outcomes you can enable.

As you grow your career, keep up with trends and start to learn about them. Take on projects that are a bit out of your wheelhouse as a way to learn new skills and spaces. Rethink how you measure success. Early on in your career, you focus on your individual success as you are trying to stand out in the crowd. But later, you realize that your larger influence is what opens up opportunities. Additionally, communities such as the TODO Group (https://todoggroup.org) are places to meet people in the same transition that can help guide you.

Additionally, as we talked about in Chapter 6, Making Your Project Feel Welcoming, Chapter 7, Growing Contributors to Maintainers, and Chapter 8, Dealing with Conflict, it’s important to engage others in humility and kindness – which is the next pattern we will look at.

Treat others with humility and kindness

If there’s one thing I’ve learned in my career, it’s that when I do good by others, in time that goodness comes back. I look at my early days in the PHP community as I started work on the PHP Windows installer. What if when Microsoft approached me about some issues they wanted fixed, I reacted with “Oh Microsoft, you are so mean to open source. I’m not helping you.” Maybe I’d get a high-five from the anti-Microsoft crowd, but would that have hurt opportunities down the road with SugarCRM, Bitnami, and the Linux Foundation – all of which have good relations with Microsoft?

As I talked about in Chapter 8, Dealing with Conflict, with open source participants across geographies, genders, races, sexual orientations, and beliefs, it is a space where being understanding of others goes a long way. For me, being able to be a leader in open source means I have to learn from these communities to best serve them, so reacting harshly and making hasty judgments doesn’t get you anywhere.

Enjoy what you do

In Chapter 8, Dealing with Conflict, I mentioned that when asked about what are the best and worst parts of open source, I cheekily replied “the people.” One of the skills that was the hardest for me to learn as I transitioned from being an individual contributor to a community manager was the people management aspect. One fellow community manager at the time told me “hacking code is trivial, hacking people is hard.”

What has always kept me going in communities is the people and the technologies, and when those motivate me, the minor skirmishes from day-to-day activities are really minute. Once in a while, communities I’ve been a part of have become too overwhelming, and stepping away was a healthy choice, but the vast majority of the time, having humility and kindness has given me joy in the work I’ve done with open source communities.

You have to find that joy as well. Work in communities with people you enjoy working with, and on technology and using tools you enjoy using. Be careful about obsessing over a project, as it leads to burnout, as we talked about in Chapter 9, Handling Growth. Not every day will be the best day ever, but you should be able to look back and be proud of your work and happy about the interactions you’ve had with others.

Let’s look at open source careers from the aspect of employers. First, let's see how organizations can use open source to find talent.

Finding talent through open source

We talked earlier in this chapter about how software development and technology jobs, in general, have become more specialized in many cases as the breadth of technology grows. Add this to the fact that technology jobs are shifting more and more to remote opportunities (meaning employees working from home rather than within a traditional office). This has made it tremendously difficult to find talent to fill the roles companies have, as well as to retain that talent. We’ll talk more about the retention part in the next section, but first, let’s look at ways that employers can leverage the open source communities they work with to find talent to fill open roles.

Participating in communities

The easiest way to find talent in open source communities is…show up in the communities. Isn’t it obvious? Well, not always. As we talked about in Chapter 6, Making Your Project Feel Welcoming, sometimes these open source communities aren’t the simplest to navigate if the project hasn’t intentionally created a smooth on-ramp for new community participants.

If the community doesn’t have a clear way to get involved, ask. Many open source projects don’t see companies wanting to get involved, and when they do, it can be one of those star-struck moments like I had with Microsoft earlier in this chapter. You will occasionally run into a project that is hesitant or not interested in corporate involvement, and that’s okay. You have to be respectful of the project and its culture. In these cases, actively trying to find talent will be hard, so taking an approach like the one outlined here might be better:

1. Have your staff software developers contribute to the project in the same way other developers contribute to the project.
2. Focus on building camaraderie with the other maintainers and growing respect for others. Ensure the developers follow all the contribution guidelines they have set forth. Have them be active in the project’s communications channels.
3. As your developers are working on the project, have them get to know other contributors and maintainers. If those contributors and maintainers are seeking a job opportunity, then have your company’s developers mention any open positions the company has available. Don’t be pushy or overly public about it; only share when someone asks.

Point 3 is important – you don’t want to look like you are trying to swoop in and hire all the developers. Position yourself as a helping hand. You will encounter communities who frown at this passive approach. If that’s the case, it’s best to avoid directly referring developers from the community and instead add knowledge about the project as a “desired skill” to your general job posting.

If the project does have more of a clear-cut way to get involved, they may have forums or job boards they maintain to direct hiring opportunities. The Zephyr Project provides such a job board on their website (https://www.zephyrproject.org/careers/), with defined guidelines on job posts, and they have additionally established a #job-postings channel in their Discord. Sometimes these channels are maintained outside of the project itself. For example, the Golangprojects site (https://www.golangprojects.com/golang-remote-jobs.html) is maintained independently of the project by a company that participates in the community.

When community members look at companies wanting to hire developers from the community, one key factor is how much the company is “giving back” to the community. While one part is certainly putting in developer resources, many projects have additional needs around infrastructure; let’s look at how to best do this as a company now.

Sponsoring project-related infrastructure

The amount of high-quality tooling available freely to an open source project is immense compared to a decade or two ago. Tools such as GitHub, GitLab, SonarCloud, 1Password, Confluence, JIRA, Netlify, and others are made freely available to open source communities, often as those companies are huge users of open source and see making that infrastructure available open source broadly as a way to give back to those communities.

If you are part of a small company or one without developer tooling it could provide to an open source community, you might think that there isn’t a way for you to help a project out in such a way. But there are often gaps in the project that frankly just need someone to foot the bill. These might include the following:

• Specialty hardware, such as GPU test runners, hardware for niche architectures (arm64, ppc64, and s390x are some I commonly see), or a specific data center or lab configuration. The project will often try to provide best-effort support in these cases, so stepping in to provide this missing infrastructure that can be part of their CI/CD processes can be a huge help.
• Web conference tooling. While many platforms, such as Zoom and Google Meet, are available for free, they can be limited in terms of meeting duration or the number of attendees. We have a local Big Data Meeting group in the Cleveland area (https://www.meetup.com/cleveland-hadoop/) that I started providing the use of my Zoom account for, which supports up to 500 users for their meetups during COVID, and they still use it, which has been very helpful as they now have a hybrid meetup that attracts people further outside the Cleveland area.
• Swag (an acronym for Stuff We All Get – think of things such as t-shirts and stickers with the project’s logo) and funding sending out swag. You might not think of swag as project infrastructure, but as we saw in Chapter 6, Making Your Project Feel Welcoming, and will see in Chapter 12, Marketing for Open Source - Advocacy and Outreach, it builds the project’s brand and notoriety as a tool to help recognize key developers. One thing I will note: unless the project is explicitly okay with it, don’t put your company logo on the swag; it’s generally in poor taste as it appears as free advertising for the company.

Open source community members rarely see each other in person. There are projects I’ve worked on for years and might have met the maintainers once or twice, but that is the exception. When people get together, great ideas emerge, and a closer community forms. This costs money; paying for a meeting space, travel costs, food, and so on. This is a great opportunity for a company to help. Let’s look at that now.

Sponsoring or hosting a mentorship, hackathon, or another event

Events are important for an open source community. In addition to great ideas and community building, it gives the project visibility to the outside world. Whether it be a vast community such as Kubernetes or the Linux kernel, or even a more niche community such as OpenVDB – it’s like a shot in the arm for community health.

We will talk a bit more about strategies for events for a project in Chapter 12, Marketing for Open Source - Advocacy and Outreach, but here specifically, I want to think about how a company can best support events for a community. Some ideas I’ve seen work well include the following:

• Giving the project an in-person event the company runs. This works especially well for projects specific to a vertical industry or specific application ecosystem. When I was community manager at SugarCRM, I started an “un-conference” as part of the event. These un-conferences were really just spaces for informal discussions and ad hoc talks, which were selected based on the attendees to the un-conference. This was great as we had several open source extensions to SugarCRM, and those developers could get together in person and collaborate across projects – even pulling in SugarCRM staff developers. It typically is low-cost for a company to do this – and generally demonstrates a lot of goodwill to the project community.
• Pick up the tab for a speaking track or developer room at a broad open source or related technology conference. There are many open source and technology conferences that are broad, such as the Linux Foundation’s Open Source Summit (https://events.linuxfoundation.org/open-source-summit-north-america/), FOSDEM (https://fosdem.org/), Linux.conf.au (https://linux.org.au/linux-conf-au/), and many more that target specific regions. Some events give space for open source projects at no cost, but there might be costs for food and beverages, audio/video equipment, or internet access. All these items make a big difference to the experience for an attendee.
• Include the open source project in talks your company might be giving. This one you want to be a bit careful with as you want to keep a separation between the project and any products your company might offer, but if you think more in the context of talking about how your company uses several open source projects together (for example, React, GraphQL, and Node.js), it raises awareness of the project, shows the project is ready for production usage, and gives others ideas on ways to use the project.
• Give the project your offices for a local meeting. Even pick up the bill for food for the group. Local meetups’ biggest challenge is space, and your company providing that usually costs you nothing and makes your company name synonymous with giving back to and supporting the project community.

Thinking outside the box of traditional events, there are other gatherings that companies can help sponsor and support to gain the interest of the project and build the community. Two ideas I’ve seen are the following:

• Host a hackathon, which is an event that brings together developers to build interesting add-ons or tools for a project, or perhaps focuses on new features or bug fixing. This is something we will talk in more depth about in Chapter 12, Marketing for Open Source - Advocacy and Outreach, where we will talk about all the required components to make this work – many of which cost money and are opportunities for a company to sponsor.
• Fund or host an internship or mentorship where the intern or mentee contributes to the project. We talked about mentorships in Chapter 7, Growing Contributors to Maintainers. Funding stipends or gifts for mentees or providing mentors for a project help the project enable new contributors, but further, the company gets a great “try before you buy” experience working with individuals the company could offer a job to afterward.

There's one key thing I cannot stress enough: as a company, you are providing these contributions in stewardship, and not for commercial gain. If you have a bunch of HR recruiters at these events, the community will be suspicious of your company’s intentions. Remember how I spoke about a “passive” approach in the previous chapter – taking that here shows the community you are investing in its success.

That talent you attract is most likely interested in your company because they know that working for you means they will still be able to participate in that open source community – and likely contribute to other open source projects as well. If your company doesn’t provide that, it might lead to these new employees being “flight risks” to other companies that do allow and encourage open source community participation. Let’s look at how to retain and recognize those employees that are active contributors to open source.

Retaining and recognizing talent coming from open source communities

We talked about recognition of a company’s employees for their contributions to open source at the end of Chapter 4, Aligning the Business Value of Open Source for Your Employer, and when your talent comes from leaders in the open source community, it is critical to ensure those contributions are highlighted and celebrated. When it’s not, not only does the company walk away with a poor reputation, but the project suffers as well.

Further, bringing in talent from open source communities often is a catalyst to improve a company’s internal development processes. Open source community leaders and maintainers are of a culture that sees openness and collaboration as the way to build better software, faster and more efficiently. We’ve seen a trend known as innersourcing emerge in organizations, where the processes of open source development are applied to a company’s internal, proprietary software development, which opens up collaboration and communication between different areas of a company. I won’t dig much into innersourcing here but do encourage you to read more about it at the Innersource Commons (https://innersourcecommons.org/).

On the topic of recognition and retention of employees coming from open source communities, the place to start is measurement. It’s usually fairly easy to track contributions and impact made internally on products the company develops or applications built internally. But contributing externally – that can be a bit more challenging, as it’s more of an indirect benefit to the company rather than direct. Further, imagine a company with multiple divisions, and offices in multiple countries, all with separate development teams – being able to have a view of the open source engagement of that company is a lot of work to stay on top of (in fact, many companies are surprised to learn they are contributing to or even using open source). Let’s start by looking at the measurement and management of open source engagement by a company.

Measurement and management of open source engagement

Let’s look at the scenario I just illustrated – a company with multiple divisions, offices in multiple countries, and software development teams unique to each – and think first about risk management. How can a company know whether there was intellectual property (IP) contributed to a project that a company might not be comfortable with? Or whether the projects being used by a division are under a copyleft license (which we discussed in Chapter 3, Open Source License and IP Management), and mixing internal code with that open source project’s code might require open sourcing a part of your product? This is usually the primary driver around the formation of an Open Source Program Office (or OSPO for short), cataloging open source use in a company, ensuring compliance with open source licenses, and overseeing contributions made to open source projects.

As an OSPO matures (check out the resources of the TODO Group for a maturity model for open source projects), the focus becomes more around capacity building rather than compliance. Mature OSPOs work across the organization to advocate for the use of open source. Part of the work they will do is to track that usage and see where they can improve participation. For example, maybe one software development team is doing a great job working with an open source project, proposing code fixes, answering questions, and generally working upstream (remember that means doing development on the open source project itself, not creating their own fork with their own changes). Another software development team is at the other end of the spectrum – uses the project, doesn’t participate in the community, and doesn’t share any code fixes back with the project. Here’s an area where an OSPO can help by giving the developers in the latter example support and training, and even recognizing when they improve their participation to be more aligned with the guidelines the OSPO lays out. And for the former developer team, they could be ambassadors to other divisions.

We often see talent coming from open source communities as natural leaders within an OSPO. After all, these individuals have a great sense of how open source communities work, which makes them ideal persons to mentor and guide a company’s software development teams in participation in open source communities.

One major challenge companies run into is seeing how the work done in open source weighs with the work they do directly impacting the company. This usually comes down to employee goal setting – let’s look at that now.

Setting annual goals

In most companies, there is an annual review cycle, where the employee has a set of mutually agreed upon goals for the year. Success in achieving those goals often aligns with compensation increases, promotions, or bonuses. Good goals are considered SMART goals, which stands for Specific, Measurable, Achievable, Relevant, and Time-Bound. Often those goals are subsets of the management’s goals, which most often are focused on revenue growth. As we spoke about in Chapter 4, Aligning the Business Value of Open Source for Your Employer, the impacts of open source on revenue are indirect, and further, aren’t well time-bound as the timelines for work on an open source project are out of the company’s control.

Let’s go back to the chart I showed in Chapter 10, Commercialization of Open Source.

Figure 11.2 – Projects, Products, Profits cycle of open source sustainability (https://www.linuxfoundation.jp/wp-content/uploads/2017/09/Virtuous-cycle.png - CC by 3.0)

You can see there is a correlation with company bottom-line impact – does the open source project being invested in help the company reduce R&D costs, get to market faster, attract more customers, and/or add new features? If the answer to any of those is “yes,” then the investment from the company in the project continues.

What does this mean for an individual developer? This means if a company is dependent on that project, a developer doing work on that project that is continuing to drive the value around cost, time to market, more customers, or more features works well. Some ideas for goals could include the following:

• Be a top 10 contributor to the project
• Upstream X new features or fixes to the project
• Improve the performance by x%
• Do a security audit of the project and resolve any known vulnerabilities

Another angle could be expanding the use of open source, perhaps bringing in a new open source project to replace a homegrown logging tool, or moving from a commercial developer framework to an open source one. These are impacts to the company by using code with more usage and, theoretically, better quality, security, and performance, as well as reducing risk by leveraging open source components versus proprietary ones that cause vendor lock-in.

A good OSPO will champion the use of open source in a company. One way to do that is public recognition. Let’s look at ways to do that.

Create an internal awards or incentives program

Companies often have internal awards and recognitions for all sorts of things, such as top salesperson, best marketing campaign, or highest support ratings. Open source contributions and impact can be similarly rewarded.

This is an area that has evolved over the years. One large multinational technology company I know of used to pay out spot bonuses to developers who got code accepted into the Linux kernel. As it turns out, a lot of the reason for that was due to the high level of legal review and scrutiny that a contributor had to go through to even propose a code fix to the Linux kernel project; then comes the scrutiny of the project itself. Many saw the bonus as not commensurate to the work needed to actually get the contribution accepted. Over time, that was streamlined and contributions were much easier, but then the company removed that generous bonus.

There are some great ideas that come from welcoming newcomers to a project that we chatted about in Chapter 6, Making Your Project Feel Welcoming. Here are a few that I’ve seen work well:

• A special recognition the first time a developer gets a code contribution accepted. It could be as simple as a thank you note, maybe a gift card, or a callout during a company or division all-hands meeting. In bigger companies, the latter can be extremely valuable as that developer will be visible to the whole company.
• Annual awards for the most contributions made to a project, which could be a bonus or maybe funding them to attend a developer conference. Both help drive developers to look for ways to work on open source.
• An incentive or bonus for starting a new open source project, especially as, as we learned about in Chapter 4, Aligning the Business Value of Open Source for Your Employer, it’s a lot of work.
• Adding open source contributions and work as part of the requirements for more senior levels in a career path for developers. More senior developers should be pragmatic by nature, and they should be able to see how open source helps them build applications better and faster, so ensuring they have experience in that space is a key skill in a well-rounded senior developer.

OSPOs generally serve the whole company, so any programs you create should have that same reach across the whole company. Keep that in mind as you develop your programs.

Summary

We saw in this chapter how open source community participation is a career enabler for maintainers and contributors. Learning from my career story how open source participation has opened doors for me, we recognized the patterns you can apply to your career journey. We then looked at companies using open source as a path for finding new talent, showcasing how participation gains goodwill, and investments in the community are effective strategies for positioning a company as a great place to work that cares about open source participation. Finally, we looked at how companies can recognize employee participation in open source, from ensuring there is a central way to manage open source participation to ensuring open source participation is in a technologist’s annual goals, and using awards and incentives to showcase those contributing to open source.

The next chapter shifts to a topic that might be thought of as the antithesis of open source but, in reality, is a crucial part of project success – marketing. This chapter will build on the topics in Chapter 6, Making Your Project Feel Welcoming, focusing more on outbound marketing and ways to make your project more relevant in the market. Let’s dig in.