illumos is a fully open-source effort to produce a reliable, performant, and scalable operating system with leading-edge technologies and tools. We bring together a passionate community of developers and a growing base of commercial participants (Delphix, Joyent, Nexenta, OmniTI, Pluribus, and more).
illumos is the successor to Sun Microsystems' OpenSolaris project. Our culture draws heavily on the qualities that distinguished Sun engineering culture: systems engineering (component, interaction, and interface design with a strong commitment to minimalism), architectural coherence (design cooperation across subsystems), measurement-driven development (strong visibility tools, mature methodologies for their use, embedding both thoroughly in the development process). We have adapted it to work beyond the framework of a single corporate entity via federated efforts of individuals and companies with distinct interests in the technology (cloud infrastructure, storage systems, application servers, and others), sharing an interest in commodity hardware and production-driven innovation.
illumos features an unparalleled combination of technologies, including the resilient ZFS storage system, production-safe dynamic tracing (DTrace), FMA predictive self-healing, the Service Management Framework for persistent process and boot management, zones for lightweight isolation and virtualisation, the KVM hypervisor for full system virtualisation, Crossbow for virtualised networks, a high-performance kernel CIFS/SMB client and server, boot environments for safe upgrades, and the MDB kernel and application debugger. All of these subsystems are actively developed by the illumos project. Both ZFS and DTrace have been ported beyond illumos (notably to FreeBSD, OS X, and Linux), where our community and sister OpenZFS community have taken a leading role in coordinating new feature development across platforms, serving as a reference platform and repository.
illumos, operating system, unix, kernel, dtrace, zfs, openzfs, virtualization, device driver, c, python, c++, solaris
#illumos on chat.freenode.net
Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?
Our previous GSoC efforts have greatly helped bring in talented long-term contributors, even in addition to the applicants, and break ground in new areas. GSoC allows us to work with an excellent talent pool from a much wider range of institutions and geographies than we could hope to engage otherwise.
Also, GSoC has proven an extremely valuable link to the larger open source community and a forum to engage on issues like community building and development process. We hope to recruit new contributors and encourage fresh ideas, mature our processes, and deepen our ties to similarly minded open source communities.
How many potential mentors do you have for this year's program? What criteria did you use to select them?
We have confirmed the availability of three mentors so far, with more selected from established contributors and reviewers, drawing heavily on "advocates", senior community members who ensure that changes are well-defined, tested, and reviewed before they are integrated. Without explicitly requiring it, we have also drawn more or less exclusively on community members with professional experience of development for our project.
What is your plan for dealing with disappearing students?
We require students to report progress weekly via our developer list and to provide prompt updates to their mentors whenever they experience setbacks. Students are told that their proposal schedules and deliverables are considered contracts: renegotiation is acceptable if it happens as unforeseen issues arise, but waiting for evaluations to raise significant issues is considered a breach and grounds for a failing evaluation. We've found a reasonable compromise with less frequent but regular check-ins with their mentors still allows students some flexibility in using their time while remaining accountable to the proposed schedule. We've considered publicly visible repositories during the program as an option, though not a requirement for all students.
What is your plan for dealing with disappearing mentors?
Org admins monitor for mentor responses to student updates to the developer list and regularly poll mentors to make sure that they have reasonably current status from students, are seeing working product to back that up, and are either satisfied with progress or have conversations promptly about issues. We also make sure that all mentors have back-ups who are kept in the loop on the above, as professional and personal obligations may require mentors to "tag out". We also encourage students to conduct most discussion in one of our open forums, so that others in the community can help them in addition to their mentor.
What steps will you take to encourage students to interact with your project's community before and during the program?
We have basic policies that require students to interact with mentors via developer IRC channels and mailing lists. Students are expected to take the initiative to familiarise themselves with the community, participate in discussions, and eventually become regular members through the program: not everything has to happen in the open, but students have to show that they are comfortable and proficient identifying themselves and talking about their work via community channels. Mentors are expected to guide students through community processes for peer review and integration.
What will you do to encourage your accepted students to stick with the project after Google Summer of Code concludes?
We treat students like regular community members, and our hope and expectation is that students who function well in that context and produce work they can be proud of will continue doing so. Many of our participants in previous years were students who had previous exposure to our community or were working with our code base in their coursework, and these students have unsurprisingly shown much greater ongoing affinity for and ongoing commitment to our project than students without, who tend to be active only for one summer.
Are you an established or larger organization who would like to vouch for a new organization applying this year? If so, please list their name(s) here.
In our first year we passed all of our students but had a nevertheless mixed experience: students were in India and mentors in California, and students were undergraduates with less previous experience in our field of development.
We had a more structured and satisfying experience for students, mentors, and the community generally in 2012, recruiting students with stronger backgrounds, who were able to function independently and delivered superior results (accepted proposals demonstrated far greater expertise and preparation, projects deliverables stayed on track or were more clearly renegotiated as issues arose, outcomes were more consistent with proposals).
Last year, we a selected three from a healthy number of strong proposals (though we probably received proportionally more "spammy" submissions as well!) from qualified students. The work was definitely of excellent quality and definitely consistent with the proposals, but we were overly ambitious about scope. Our mentors encountered more difficulty getting students to stay on schedule towards the conclusion of the development phase, primarily not due to the fault of the students themselves but our own difficulty in estimating the increase in time involved in testing and reviewing substantial changes with inherently higher risk. As a result, we will be sizing projects less ambitiously and providing feedback to applicants for pre-integration testing plans in their applications.
We are happy to say that despite occasional setbacks, all of our students selected so far have passed.