9 min. read

May 25, 2021

My Employer Supports My Open Source Contributions

Each month, I work on different open source projects publishing my work with an OSI compatible license and report them to our internal reporting tool.

juhis picture

Juha-Matti Santala, Developer Advocate

Open source and especially the community around it has a special place in my heart. Over the past few years, I've organized campaigns to promote open source in my local communities, hosted Hacktoberfest and DocsThursday events and hackathons and open sourced most of my personal projects I've worked on.

There are many reasons for people to build open-source projects and become contributors. For me, there have been two main reasons: giving back to a community that has helped me become a software developer and learning new skills from building side projects.

After joining my current company as a software developer a bit over 3 years ago, not only have I continued working on open source projects but also I've been lucky enough to get financial support from my employer – no strings attached! Recently I've taken a lead in the initiative so I'm able to encourage more and more people to contribute to the shared knowledge pool and library/application base of the open-source community.

What is Spice Program?

Our company-sponsored open-source and social impact program, known as Spice Program, was launched in 2013. As a tech consultancy, we build solutions on top of great open-source work and we wanted to find ways to support the open-source movement and our developers at the same time. Over 7 years, we've supported tens of thousands of hours of open source work done by our developers.

So how does it work from a perspective of a software developer like myself? Well, each month, I work on different open source projects publishing my work with an OSI compatible license and report them to our internal reporting tool. All reports are open for anyone else to see and shared automatically in our Slack. It's very encouraging to see a stream of reports from different people contributing to different projects.

And that's basically it. The company pays an extra bonus of 15 euros per hour, up to 30 hours per month (upper limit to keep people from overworking themselves). The company makes no IPR claims over the open-source work our developers do and there's no pre-approval process. Our culture is built on trust and transparency and it's working really well. Everything is also voluntary and does not affect people's career paths or progressions inside the company. You can work on open source as much or as little as you like each month.

Over the past few years, the monthly contributions are around 500–1000 hours. That's close to 10,000 hours of open source work done by developers each year!

My personal journey learning Rust

That might seems like a lot of corporate jargon, so let me share a personal experience from this spring. At the end of 2020 I decided to finally pick up Rust, a systems language that's been all the hype recently.

I've been mostly working with Javascript, Python and earlier in my career, PHP. A jump from those languages to something like Rust is quite a learning curve. After a rough start with Advent of Code puzzles, I decided that the best way for me to learn and get comfortable with Rust is to build a tool for myself.

In January of 2021, I started working on 235, a command line tool that brings NHL hockey results directly to the command line. I'm a huge hockey fan, and for twenty years it's been my morning habit during the season to check out the results of previous night's games from Finnish Broadcasting Company Yle's Teletext service, from page 235 (hence the name of my tool). I wanted to honor that decades-long cultural importance by choosing a similar visual style that focuses on the important information - scores and scorers - and nothing else.

By open-sourcing the project from the very get-go, I was able to achieve two things: first, I made it possible for anyone to see how it's built, and to contribute, give feedback and extend to their own needs. Second, it qualified my work for the Spice Program so I would get financial support for building the tool for myself and every hockey fan out there.

Over the first 3 months of the year, I’d spend my Saturdays working on the tool, reading about Rust and discussing my journey with the great people in Rust communities. And in addition to the code, I've also shared my struggles and learnings with the new language openly on my blog's Learning Rust series.

As I was working on the application, I noticed that the API I was using for the data was also built with Spice Program support back in the day. That's one of the beautiful things with open source and sharing what you've built: others are able to build on top of your work giving your work even more meaning and impact.

How to set up a Spice program at your company

If you're a team lead, tech director or in a similar kind of position at your company and would like to implement something similar, here are some ideas and tips.

I believe it's key to build this on a correct balance. It can be a win for the open-source community, a win for the developer and a win for the company. The open-source community gains more support from developers who are interested in building things for others and improving the tools they use. Developers have a financial incentive to learn and grow in a meaningful way, and the company encourages developers to grow while creating an environment that attracts top-notch developers. FYI it's great employer branding — in our internal surveys, the Spice Program is one of the top benefits our people enjoy.

Another key factor is building proper structure and understanding inside the company for what the program is for and how it functions. Any work that is related to your business or is directed by the business is work and needs to be compensated as work. Sponsoring open source work is a voluntary and no strings attached deal with the developers. Since people have different life situations and not everyone likes to code in their free time, the contributions should not be used for promotions or rewards outside the program as this creates an uneven playing field for people.

To make the program more inclusive inside the company, we expanded it to include social impact outside of just open source development so that our designers, HR or business people could also participate. But that's another story.

More information can be found from this book A Company's Guide to Open Source and Social Impact that we wrote for companies, you can download at spiceprogram.org. The book talks about the Spice Program and a bunch of other aspects around open sourcing the work you're doing for the business.