This year Embox participated in the GSoC program as a mentor organization. In this article, I would like to talk about our experience.

I will say several words about GSoC program. Google Summer of Code is a global program of Google, which aims to engage students in the open-source software world. As a result, students improve their code quality, technological literacy and skills in development processes participating in real-world industrial projects with mature development processes. This should be the main argument for students’ participation in the program. A motivation of mentor organizations is primarily the project development and expansion of the project community.

Let’s talk a little about formal rules. Only communities representing open-source projects can be accepted into the program. A project with one developer will not be selected, as you will need a lot of time to consult and work with students. An organization must fill out a short form to participate in the program, submit at least two org admins and refer to a page with ideas list proposed for students. The form includes a short project description, contact details, and the link to the ideas page. The next step is the selection of organizations. When the project is accepted, its card is published on the page of the program’s mentoring organizations and the period of students selection starts.

Selection of students is a very difficult part for mentors. Embox has participated in the GSoC program as a mentor organization for the first time. Therefore we didn’t expect so many people would like to take part in our program. Formally, the selection of students is based on proposals in which the applicants describe what they want to develop during participating in the project and how they intend to do it. But this is not enough to understand whether the student will achieve the desired results or not. This is the main difficulty for mentors at this stage of the program.

The different organizations use diverse ways to select students. During discussing ways of the students’ selection in the mailing list for GSoC mentors, someone recommended to interview them on Skype, someone suggested to prepare and check test tasks, and someone recommended to look at a detailed resume. We decided to do it in the following way. Being a student firstly you should introduce yourself by writing a short letter to some project mentor. Secondly, solve at least one issue from the list on GitHub. And thirdly, submit an official GSoC proposal on the program’s website.

The first point did not cause any particular difficulties. Yes, there were some students who submitted the proposal without introducing themselves, but we did not evaluate them. I will explain the second point a little. Embox, like all matured projects, has its own development processes and usually, students may simply lack the practice of participating in industrial and distributed projects. Moreover, Embox is an operating system. It is usually a new area for students. Therefore, before someone can contribute to the project, they need to learn how to build, launch, debug, make changes, that is, understand the processes adopted in the project, for example, git workflow.

We didn’t want to do such things in the active phase of the program when students should already work on their projects, and we tried to do it in the preliminary period. We created very simple issues labelled with “Good First Issue” on GitHub which allow understanding the project processes, show minimal knowledge of the C language, confirm the ability to read the documentation and search for information on the Internet. In fact, after a student completed the issue, we were confident that the student could make some changes to the code and prepare a pull request into the project.

At this point, the preliminary requirements for the official application were considered fulfilled. But students can continue with the project, completing other issues from the list on GitHub and suggesting their improvements and changes. The only requirement was not to take “Good First Issue” more than once. We wanted everyone to have an equal opportunity, but it was not easy for us to create a large number of simple issues. In all other respects, we tried to help everyone, starting with preparing PR and working with git, and up to explaining Embox specifics and architecture.

Those students who continued to participate in the project as far as possible wrote the very good proposals. This is not surprising, because they got a deeper understanding of the whole project.

Many proposals of these students’ were different not only in the detailed work plans but also in themes. We considered a list of ideas which we suggested on the wiki page only as examples. So we were very happy when the students began to offer us their own themes. In our opinion, it is important that the student deal with tasks that are interesting to him. We consider this as an additional motivation for students. But of course, own theme is not a prerequisite. We had very interesting ideas and a lot of students wanted to work on ideas from the suggested list.

There were more than 30 submitted proposals. There were at least five very good students who not only met the minimum requirements but also communicated with us on other issues, tried to fulfil it, suggested their own tasks and generally showed interest in the project. Unfortunately, according to the results of the slots distribution, we got only two slots for students, therefore we had to deny some of the students who we wanted to be accepted. Luckily as we found out later, some of them were accepted to other projects in the program.

We accepted two students, Eric Cafferata and Yuta Sakamoto. Both came up with their own ideas. Erick suggested implementing USB device mode for STM32. Yuta proposed to port Embox to “MAiX-Bit” board with RISC-V architecture. By the way, both of them initially chose ideas from our list. But as expected, after a deeper dive into the project, they can better understand what they want to improve in the project.

The next official stage in the program was community bonding when students communicate more closely with the community and continue to investigate the project. But since both students were already involved in the project, it was more like a continuation of the previous stage. Since we already knew what the idea the students wanted to implement, we offered them issues that were close to the chosen areas.

As a result of this stage of the program, several preparatory tasks were completed, which, in my opinion, allowed students to move more successfully according to their plans in the future.

In the summer, the main stage of the program began. It was the development or codding stage. This stage is divided into three parts a month long. After each part, an evaluation is carried out. Students are expected to work evenly. And based on the results of each month, we must confirm that the students are adhering to the plan.

In practice, we noticed different student activity during the coding period. Sometimes we even seemed that the activity was lower than at the preliminary stage. It turned out that they had started exams or were busy at school and could not devote enough time to participate in the program. But they worked very productively in other periods. It turned out that this was happening not only in our project. As a result of the summit of GSoC mentors, it was even proposed to simplify the rules and allow students and mentor organizations to agree on the work schedule of students.

Communication is an important part of a team working. Of course, Embox, like other open-source projects, has its own communication mechanisms between developers. Embox has telegram chats (developers, news) and mailing list: embox-devel[at]googlegroups.com.

But of course, You don’t want to make public some things that should be discussed with students. In addition, students are sometimes embarrassed to ask questions in general, and in addition, GSoC is an international program and there is a language barrier for some students. For example, one of our students wrote that it is difficult for him to communicate in English. As a result, we created private chats in which there were two mentors (main and secondary) to communicate with each of the students. And most of the communication on specific projects took place in these chats. Any other things (not private for student) were discussed in the public chat or GitHub in the usual manner.

The main part of the program is aimed at coding. In the early stages, students must follow the third-party developer guidelines. The main project repository must be cloned, approved and merged back into the main project repository. That is, third-party developers use their own repository. You need to switch to their repository in order to check the changes. This is fine when it comes to only verifying the changes, but when it comes to some kind of advice or a task several people work on, it can be rather difficult. We added both students into Embox team and thereby allowed them to create branches in the main repository to avoid these difficulties. As a result, it turned out to be the right decision, we worked closely with students and they gained experience in team working.

Both students completed the program successfully. Erick has demonstrated correct USB-device based on STM32 board connected to a computer with ‘lsusb’ util. Yuta has demonstrated the control of the LED, through the Embox command-line utilities. Yes, Erick wanted to add some more functionality to some device and even implemented ECM-ACM (virtual comport). And Yuta wanted to add support for an encryption module built-in in a chip. But this was an underestimation of the complexity of the proposed work. I think that the results have been achieved in three months in such a complex area as systems programming are impressive. And most importantly, the students have gained a great experience of teamwork, got to know better the world of opensource and of course significantly improved their technical skills.