-
Notifications
You must be signed in to change notification settings - Fork 0
GSOC Questions
RIOT is an open source operating system for Internet of Things devices. RIOT enables any programmer to develop applications on typical IoT devices with zero learning curve and shortened development life-cycle, using standard languages (C or C++), full multithreading and well-known tools such as gdb, Valgrind etc. RIOT implements a micro-kernel architecture that provides built-in robustness, real-time capabilities and energy efficiency with low memory footprint (needs only a minimum of 1.5 kB of RAM). On top of it sit cutting-edge network stacks (6LoWPAN, IPv6, CCN), and POSIX APIs. RIOT thus offers a modular solution that can adapt to most IoT scenarios, and take full advantage of a large range IoT hardware, from 16bit architectures (e.g. MSP430) to 32bit architectures (e.g. ARM Cortex).
Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?
The RIOT community applies to GSOC 2014 in order to get in touch with the best students from different countries interested in distributed, embedded systems and IoT scenarios. Our approach is inclusive in the sense that we want such students to become real members of the community, with ongoing contributions on GitHub etc. There are a number of projects for which we need additional help, and we think that some talented students could help us achieve significant goals. Most of the projects we propose are in fact the first phases of longer terms projects that the students may choose to contribute to after GSOC is over.
No.
No.
LGPLv2.
https://github.com/RIOT-OS/RIOT/wiki/GSOC-Idea-List
http://lists.riot-os.org/mailman/listinfo/devel
#riot-os at irc.freenode.net: irc://irc.freenode.net/#riot-os
Oliver Hahm
How many potential mentors do you have for this year's program? What criteria did you use to select them?*
We selected our potential mentors from the core developers and contributors to RIOT. Mentors were selected based on (i) how well they know the code area they're volunteering to mentor, and (ii) how they interact with others in the community, and (iii) how much time available they have to adequately mentor their student(s).
The potential mentors :
- Kaspar Schleiser, who developed the micro-kernel on which is based RIOT, and is part of the RIOT steering committee.
- Ludwig Ortmann, who developed most of the the virtualization of RIOT on Linux, the native port, and is part of the RIOT steering committee.
- Hauke Petersen, who developed the driver model for RIOT, and is part of the RIOT steering committee.
- Martine Lenders, who developed most of the 6LoWPAN network stack and POSIX APIs in RIOT, and is part of the RIOT steering committee.
- Emmanuel Baccelli, who is an expert in IPv6 protocols stack, an author of several RFCs, and is part of the RIOT steering committee.
- Matthias Wählisch, who is an expert in network communication, an author of several RFCs, and is part of the RIOT steering committee.
- Christian Mehlis, who is one of the main maintainers of the RIOT code base leads CCN network stack developments in RIOT, and is part of the RIOT steering committee.
All the potential mentors work together in different projects since several years. They have academic as well as industry background, and have extensive experience dealing with students as they all mentored (or are still mentoring) a number of students in various software projects in the recent years. It is worth noting explicitly that the selected mentors are used to educate students, which not only reduces the risk of disappearing students but also improves the learning curve of potential GSOC students. All potential mentors listed above have extensive experience in embedded design programming and/or network stack design and programming.
We believe that our selection strategy of the mentors tackles the two crucial challenges for the success of the project: disappearing students and disappearing mentors.
We learned from previous experiences that one cannot entirely avoid disappearing students. However, we can take steps to minimize the number of students lagging behind in terms of technical and social skills - a very important factor to maintain student involvement and decrease failure rate.
All the potential mentors have extensive experience dealing with students. They educated, trained, and supervised students, or still doing this, in several software projects such as programming labs and software competitions.
The goal of the project is to be as inclusive as possible from day one: we want our students to become real members of the community, with ongoing, visible contributions on GitHub etc. In our experience, such an inclusive approach encourages students. In order to further decrease the risk of student drop out, we will put in place a rhythm where bi-weekly update/meetings are expected between mentors and students to continuously discuss progress and next steps. We'll also ask our students to provide means for us to get in touch beyond email, where possible - Skype, IM, phone, etc. - in case we need to get in touch urgently.
We believe it is very important to leverage the spirit of joint work, so that people do not feel "alone", in particular when tasks are getting very challenging. We will encourage students to interact not only with their mentor but also among each other using common social media and communication platforms (we mainly use GitHub, and IRC). All students will get introduced to each other before they start coding.
We provide a "backup mentor" for each project that briefly monitors the mentoring process and can jump in quickly if needed. The admin (Oliver Hahm, who is part of the RIOT steering committee as well) will also ensure that the mentors are indeed keeping track of what their students are up to.
What steps will you take to encourage students to interact with your project's community before and during the program?*
We use GitHub, and one advantage of this platform is that the current activity of the RIOT community (a relatively 'young' community) on this platform is clearly visible and may thus be attractive for students. This attraction should lead students to start interacting with the community even before the GSOC program, and certainly during the program. We also use IRC, which should also help the inclusive process and the sense of real-time interaction that can be quite motivating.
In order to bootstrap the process, we have also designed an application template that asks for a sketch of approach, work plan, for the project that is applied for (see https://github.com/RIOT-OS/RIOT/wiki/GSOC-2014-Application-for-a-RIOT-Project ). This requirement should also encourage applicants to involve with the community before the program.
We hope we can make students feel that they're an important part of our community; be open for creative contributions and make them realize that their contributions are really making a difference towards the goals of RIOT. We will make sure they understand how important community building is for the ongoing health of this type of open source project, and they are welcome to continue to contribute to the RIOT community even after the GSOC 2014 is over.
Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here.
The veteran organization ns3 (http://www.nsnam.org) vouches for RIOT.
What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?*
Many of the projects we propose are explicitly the first phases of longer terms projects that the students may choose to contribute to after GSOC is over. This in itself should be a motivation for students to continue to contribute outside of the context of GSOC 2014. We will encourage them to consider this not just as a mere "summer job", but as first steps in an actual developer community that is ready to welcome them. We will highlight that doing something that is not only interesting for them personally but also useful for others. Moreover, the procedure to contribute to RIOT is designed to be as transparent and inclusive as possible.
RIOT - The friendly Operating System for the Internet of Things
Homepage | [GitHub] (https://github.com/RIOT-OS/) | Developers Mailing List | Users Mailing List | Twitter @RIOT_OS
- Family: ARM
- Board: Airfy Beacon
- Board: Arduino Due
- Board: IoT LAB_M3
- Board: mbed_lpc1768
- Board: MSB-IoT
- Board: MSBA2
- Board: OpenMote
- Board: PCA1000x (nRF51822 Development Kit)
- Board: UDOO
- Board: Samr21 xpro
- Board: Spark Core
- Board: STM32F0discovery
- Board: STM32F3discovery
- Board: STM32F4discovery
- Board: yunjia-nrf51822
- Family: ATmega
- Board: Arduino Mega2560
- Family: MSP430
- Board: MSB-430H
- Board: TelosB
- Board: WSN430
- Board: Zolertia Z1
- Board: eZ430-Chronos
- Family: native
- Board: native
- Family: x86
- Board: Intel Galileo