! This post is also available in the following languages. Japanese, Korean, Chinese (Traditional)

LINE Open Source Sprint 2021: Promoting open-source contribution

We at the Open Source Program Office TF are working diligently to close the distance between LINE’s development culture and open-source development culture. With how many of LINE’s developers are dependent on open-source software, many of them may have had one of the following thoughts at some point:

“One of these days I should really try contributing to an open-source project…”

Followed by another thought:

“But I don’t even know where I should start!”

As we are well aware that many developers are having these concerns, we’ve planned and held a company event to promote open-source contribution. This post is a summary of our experience from the 2021 Open-source Sprint event. 

 

About the event

The Open-source Sprint was an event to gather many developers in one place to contribute to open-source projects. LINE is host to many of its own open-source projects. The Armeria Project is one of those projects, and in 2019 we used the project for short-term open-source contribution mentoring (Armeria Sprint). To summarize the atmosphere from the event, many people gathered to contribute to the Armeria project by solving issues, developing, asking questions, and opening pull requests. 3 years later (time sure flies!), some of the people who were present at the event are still dedicated to contributing to the project as of this day. They started as novices, but have since honed their skills to the point of being able to mentor others.

As one of the people responsible for planning the event, I was proud of the outcome, but at the same time felt that there was some unfinished business we needed to take care of. As I’ve previously said, LINE has many open-source projects, and each of those projects also needed more contributors.

That is why we have expanded the participating projects to all LINE open-source projects this time. Many of these projects were first conceptualized because there was a specific internal demand, and then later published as open source. The main userbase for these projects were naturally LINE employees, and they had plenty of time and experience with these projects in their day-to-day work to think about features they would like to add or any bugs that needed to be fixed. An added benefit was that the project maintainers were (albeit, virtually) right next to the contributors and available to offer advice. 

The details of the event were as follows. 

Duration
  • Scouting projects: 1 week
  • Preparations: 2 weeks
  • Gathering participants: 1 week
  • Development: 3 weeks
Participants
  • Project: Open-source projects published by LINE
  • Participants: Any developer of the LINE group

 

Details of the event

 

Scouting projects

We grouped projects and developers as participants, and then began to scout potential projects first, so that we could gauge the scale of the event. As there were many who were participating in this sort of event for the first time, we gathered the open-source maintainers and explained the background of the event, and what kind of roles we needed. Then we determined which projects need more contributors, and whether there were enough resources to handle new contributors. As a result, we narrowed the projects down to the following four: – ArmeriaCentral DogmaDecatonLINE FIDO2 Server 

 

Preparing tasks

Before the actual event, we made sure that each participant could at least open one pull request during the event. For even those who are very interested with open-source contribution or have much experience with the project in question, the initial barrier of entry for contribution can be high. We had the maintainers create issues that could be solved by our novice contributors, so that the barrier of entry was lower. These issues were labeled as good-first-issue and first-timers-only so that contributors could easily identify them. During the preparation of these issues, we could also estimate the maximum number of participants as well.

As a side note, we had something interesting happen with the good-first-issue label. While these issues were purposely made for our event, contributors from outside of the company saw these issues as a good opportunity to get involved with these projects, quickly depleting the material we had prepared for the event! After this happening, we prepared more issues for our participants, but this time we planned to brief our participants in person rather than registering them as issues on the repositories.

 

Recruiting participants

As we have done when first scouting for potential projects for the event, we had a briefing session where we explained the details of the event to the participants. Since we have developers in several groups internationally, we had Korean, Japanese, Chinese, and English interpretation prepared. I’d like to once again thank the Support Team and all the interpreters that helped with the event! (We may rely on your help again in the future!  🙂 ) In the briefing session, we explained the details of the event and what roles we expected the participants would play. We also heard some testimonials from those who participated in the previous Armeria Sprint, encouraging the new participants. After the briefing session we had the participants sign up to each project on a first-come-first-serve basis. As our participants had to dedicate some time out of their work hours for the event, we also went ahead and explained the event to each of their managers. 

 

Development

Finally, the event began. The participants and maintainers for each project introduced themselves, the project, and what needed to be done during the event. We sadly had to stick to video calls due to the ongoing pandemic. Although all LINE employees are perfectly comfortable with communicating over video calls due to working at home for years at this point, we had concerns because the whole point of the event was to help those who “didn’t even know where to begin”. We decided to set a few ground rules to handle these concerns.

  1. Only develop during work hours. → Managers of the participants would be notified in advance.
  2. Gather at the virtual space on the agreed upon time.
  3. Maintainers would see to their daily duties while waiting for participants in the virtual space.
  4. Participants would freely ask questions and discuss matters with the maintainers who were standing by. 
  5. Handle any other communication on Slack. 

We remembered the time during the first few weeks of working at home, when it was awkward for us to use video calls for our work. We were initially worried that maybe everyone would feel awkward again while using these virtual spaces. Contrary to our worries, everyone was soon engaged in active discussion due to their common interest in open-source development. 

The participants in active discussion. Looks like a certain “friendly neighborhood developer” also dropped by!
It was amusing to see everyone working while sitting at each of their seats even in a virtual space. 🙂

 

Closing

4 weeks of development time had passed. Each project selected an MVP out of the participants that were the most active and enthusiastic during the sprint. All participants gathered to congratulate the MVPs, exchange their thoughts and experiences, and the event came to a close. 

You can see the participants sharing their results and exchanging their thoughts in the image below.

We awarded the maintainers and the MVPs with trophies recognizing their hard work. We also gave out calendars of the year 2022 for everyone who participated.

 

How did you come up with the event?

The event was planned with three goals in mind.

1. Establish an environment where you can develop and contribute to open-source projects as part of your daily routine.

LINE uses open-source software from a variety of fields, and that’s why we believe that we should integrate open-source development and contribution naturally into our own work. Modifying and using an open-source project, but not contributing to the upstream would keep us limited to that specific version, and as a result it may remain as legacy software. Only using and not contributing to an open-source project does not influence open-source development in the slightest.

Moreover, developing and contributing to open-source projects in daily work is integral to cultivating our development culture. One of LINE’s main keywords in terms of development culture is growth. And one of the topics that keep coming up again and again when discussing developer growth is open source. We believe that it is important to encourage our developers to use, develop, and contribute to open-source projects in their daily work as a part of our development culture that promotes growth. 

2. Promote open-source policies and offer first-hand experience.

Our team creates and manages various policies and processes related to open source. However, a good policy wouldn’t amount to much if they aren’t known to the ones they affect. We wanted the event to be a place where we could promote our open-source policies and let the participants get some first-hand experience. While the participants may only be a small percentage of the entire LINE group, we trust that they will spread the word to their colleagues. (We trust you guys!)

3. Provide resources for LINE open-source development.

Open-source development can very easily turn into a lonely battle. Expectations can be high, participants can be few and far between (or you could be alone), and there is an endless amount of work. In situations like these, what a maintainer would need most is support from a colleague that shares your goals. One of our goals for this event was to connect novices with maintainers so that they may become long-term contributors.

Another consideration is that someday contributors may join these projects from outside the company. Maintainers were able to learn what the average contributor requires, and what improvements they can make to their project documentation. A well-prepared project will make it easy for new contributors to jump in right away and start working on improvements.

 

What were the results?

Here are the results from this event.

A total of 25 participants submitted 24 pull requests, and by the end of the event, 12 of them were merged! Activity continued even after the event was over, and as far as I’m aware, a total of 20 of the pull requests were merged as of mid-February. We applaud those who haven’t given up even after the event concluded, and those who are still challenging themselves to get their tasks done.

Next, let’s take a look at the contributions made by our participants. (A single pull request may contain several contributions.)

New featureDefectBreaking changeImprovementDeprecation
175221

As expected, New feature contributions were the most popular. Defect contributions, which were tasks set up to solve a problem, was the second most popular category. There were participants that managed to make contributions in categories Improvement (making an improvement), Breaking change (changes that affect compatibility), and Deprecation (deprecating a previously available feature), despite being fairly advanced for novices and requiring more in-depth knowledge of each project.

The top 3 responses from an after-event survey were as follows.

SatisfactionProsCons
Extremely satisfied43.8%Meeting new people, making relationships62.5%Event was during work hours25%
Satisfied56.3%Event was during work hours37.5%Not satisfied with own results25%

Satisfied with own results37.5%

It was interesting to see that participants had polarizing opinions on the same topic. Some were glad that to participate during work hours, but some weren’t. I suppose it’s not easy to satisfy everyone.

 

Takeaways

After the event was over, we had a postmortem with the participants. I felt a sense of pride as I saw that everyone was much closer to each other than when we first began. Here are some of the opinions that we got out of the postmortem. 

  • I was able to finally rise up to the challenge of contributing to an open-source project thanks to the event. I wish we could have the event every year.
  • After my first success, I felt like challenging myself to try and fix other issues as well.
  • While I don’t actually use the open-source project I worked on normally, but it was a technology that I had an interest in. I was able to learn more about the related technologies and it helped me a lot in my work.
  • Everything was possible thanks to the kind help from the maintainers. It was a wonderful experience and I hope there’s another in the future.
  • I’ve only used a small part of the open-source software in my work, but through this event I learned a lot more about the core features. It helped me use it to its full potential in my daily work and gave me the confidence to keep contributing to open-source projects.
  • At first, I just participated to read the source code of the software that I used in my work. I haven’t finished my task yet, but I won’t give up.
  • Since we used video calls, it was easier to get a closer look at the source code. Because of that, the language barrier wasn’t so much of an issue.
  • The Armeria Sprint was offline, and we had to spend a lot of time confined to a single meeting room. We had to intensely focus in a short amount of time because of that, and it wasn’t easy. This time, we worked remotely, and that made things more slow-paced and easier.
  • Using a virtual space to communicate was interesting. We spent a lot of time in that space, but we also had one-on-one time in a separate chat if we needed to. Overall, we had a lot more time to talk, which was good.
  • The participants were passionate, even though it couldn’t have been easy while also attending to their main work tasks. I was impressed that a lot of them even managed to get their pull requests merged.
  • It was a good experience for me as a novice maintainer. I learned a lot about open-source project management.
  • I sincerely hope this isn’t a one-time event. Even maintainers sometimes don’t have a full grasp of their projects, and contributions often open your eyes to things you weren’t aware of. It was very helpful.
  • Maybe it might be more fun if we used VR in the future? 🙂

Looking back, we’re motivated towards making a great event for 2022. Moments like these are what makes open-source work all worth it. Moments of people cheering, encouraging, and trying their best made everyone in attendance glad to be there. We will continue to work towards an environment that’s welcoming to even more people. Thank you all and see you again!