illumos is a fully open-source effort to produce a highly 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, DEY, Joyent, Nexenta, OmniTI).
illumos is the successor to the OpenSolaris project, and our culture draws heavily on what 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 highly reliable ZFS storage stack, dynamic tracing (DTrace), FMA predictive self-healing, SMF for persistent process and system resource management, zones for lightweight isolation and virtualisation, a port of the KVM hypervisor for full system virtualisation, Crossbow for virtualised networks, a high-performance kernel CIFS/SMB client and server implementation, 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 has taken a leading role in coordinating new feature development across platforms, serving as a reference platform and repository.
Organization Home page:
Main Organization License:
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). In both years we passed all students.
We anticipate benefiting from GSoC 2013 in much the same way we have done in previous years. 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, cement existing ones, and deepen our ties to similarly minded open source communities.
To subscribe to our development mailing list, visit:
For other lists, including our general discussions, see:
#illumos on irc.freenode.net
We selected 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 issues arise, but waiting for evaluations to raise significant issues is considered a breach and grounds for a failing evaluation. We provided for a good deal more structure last year (e.g. WIP repos to monitor code check-ins at least once a week), but, as our students were largely working in graduate programs and accustomed to working with reduced supervision, we found that we did not need to require as many regular check-ins with their mentors as we had initially expected.
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".
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 function as regular members of the community throughout the application process: 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.
We treat students like regular community members, and our hope and expectation is that students who function well in that context and produce good work will continue doing so. Our 2012 participants had a majority students who had previously been engaged in 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.