I must start by thanking Mel Chua for visiting us in Connecticut and for prompting/prodding me to think more deeply about how open source and academia work together to accomplish education. I believe I now have a better picture of student and academic participation in open source projects.
At first look, student participation in open source projects seems like it should be relatively easy to accomplish. Sure, from a teaching perspective there are issues related to selecting a project, learning curve for the project, finding a mentor, identifying ways that students can participate, figuring out how to grade things, and more. But these things are surmountable.
But in recent years, some rocks in the river have appeared that make navigating the current of open source involvement trickier than it first seemed.
When two groups collaborate, they typically do so to accomplish common goals or to work together towards goals for both groups. In this case, the goals of the two environments differ. The open source environment seeks to create a product that meets user needs. The academic environment seeks to produce students with a certain knowledge and skill set. These differences need to be understood in order for academic and open source project collaboration to be successful.
Open source communities would like to see larger numbers of developers contributing to their projects (as would I). And some in the open source community view students as a possible source of future development (I happen to agree). Academia sees open source as an opportunity for students to gain real-world experience, learn professionalism, and have some evidence of software proficiency that they can demonstrate to potential employers. Making a contribution is helpful, but not essential.
Can open source and academic collaborations accomplish the goals of both groups? I think so, but there are some differences in the environments which present... well, we'll call them "learning opportunities." In order for a particular collaboration to be successful, it helps if both groups understand these differences.
While talking with Mel, it became clear how much the two environments differ with respect to pace, planning, and constraints. The open source way is very opportunistic and flexible, while academia is very planned and structured. The open source way emphasizes short-term optimization and taking immediate advantage of resources (for example, developer expertise, time, or funding). Resources can appear and disappear relatively quickly in the open source environment. With the fluid nature of both resources and participants, it is difficult to estimate long-range (one or more years) results. This is not to say that open source projects do not do long-term planning, but that the development process is sufficiently flexible to allow projects to change paths or goals as new opportunities open up.
Academia is built around concepts of long-term optimization and resources allocated over time. Academics have a fairly fixed set of resources (for instance: time, instructors, students) which vary little over the long term (several to many years). In addition, academics operate under a series of constraints. Academic resources are bound by time limitations, such as semester schedules and class hours. They are bound--obligated--to syllabi, learning outcomes, and grading. These things cannot typically be changed within a three-to-four-month timeframe, and sometimes not within a year. This limits the ability of academia to take advantage of the opportunities that arise spontaneously from open source.
The pace of the two environments is also different. The open source environment tends to be fast-paced and less predictable with an intermittent pattern of effort as people have more or less available time to contribute. Academia has a much slower pace (some might say glacial) with higher predictability.
The academic schedule is certainly predictable. Class schedules are often created six to eight months before the term starts. In addition, curricula plans encompass all four years of a student's stay at an institution. Therefore, classes must be supplied to meet the curricula that was in place at the time that a student entered the institution. In addition, changes in curricula are typically phased-in over a four-year period.
Clearly, there are also large differences in culture. But I think that collaboration between open source and academic realms can work, as there are also some strong commonalities between the groups. The open source and academic environments both share the desire to create something, to produce a product that people will use. Both groups have a love of learning and both groups are based on the idea that something (whether it is knowledge or software) should be accessible to everyone. Both groups have a desire to belong to a professional group, to be interacting as professionals and participating in ongoing professional activity. And interestingly, I think both groups share the desire to be self-directed and to have control over what they do.
So what else have I learned, as a professor trying to get more students involved in open source? Lots!
Participation in open source definitely benefits students. I have watched students gain invaluable professional knowledge and experience, growing skills and forming professional networks through participation in open source. Many students are motivated by participation in open source projects in a way they aren't in a traditional classroom. They better understand of how the seemingly esoteric things they've learned in their courses matter.
Setting expectations is important. Expectations are important--for both the student and for the open source community. The differences in cultures identified above must be understood by both groups in order to support a successful collaboration. The actual methods and manners of participation in the project may look very different from the academic and open source perspectives.
I can be more opportunistic. My preferred approach is to plan things out well in advance. Talking to Mel made me realize that there were lots of opportunities that occur spontaneously. With little effort, I could take advantage of these opportunities if I'm willing to alter—or abandon--my plan.
For instance, with two days notice, Mel and I set up a Hack Share where we invited Sebastian Dziallas to come hack (live and in-person) and teach students how to package an application. I would not have attempted this on my own, assuming that I would need lead time to advertise, get resources, secure a location—all the details. However, Sebastian's talk was very well attended and a huge success on a small scale.
Could I have gotten a larger attendance? Sure! But not in my window of opportunity. With little time to plan, the Hack Share reached only a small number of people. But if I refused to try because of the immediacy of the opportunity, the event might not have occurred at all. The trade-off is to reach fewer people in smaller ways, but with a larger number of experiences. The conversations I've had with Mel—and the success we had with this quickly formed event--encourage me to take advantage of opportunities that arise.
Academia needs to be sure to give back to the open source community. One very real danger of student participation in open source software development is that students will learn from the community, gain from the community, and then not provide anything back to that community. This violates the open source way and could easily break up open source/academic collaborations. In my opinion, the onus is on professors to find a way to provide some return value to the open source community. This value does not necessarily need to be in the form of code, and could easily take the form of documentation, wiki gardening, or other needed tasks.
I believe that our efforts involving students in open source projects will pay off for the open source community—in the long run . It may be many years before these benefits will be reaped. I say this for several reasons. First, most students are focused primarily on their degree and then on getting a job. These are folks who are (rightly so) spending most of their energy on establishing careers. This means that for at least a year (perhaps longer) after graduation, these folks may not have time to contribute to open source projects.
Second, I believe that students will carry the banner for open source, but that it will take time for the idea to spread. Remember that students are not professionals and they are learning how to participate openly, in addition to the material in all their other classes. They typically have a much longer entry timeframe into open source than an experienced developer.
Lastly, academia moves at a snail's pace compared to the open source world. It will take time for professors to understand the opportunities offered—and the social obligations necessitated--by involving students in open source. And it will take them even longer to change their own classes to include open source; longer still to have open source integrated across a curriculum.
These observations have both positive and negative repercussions for the open source community. The bad news is that there is not likely to be a huge influx of new open source developers--graduating college students familiar with the open source way--in the near future. This is compounded by the fact that the number of computing students has not yet recovered from the steep decline in numbers that occurred in the 2000s.
The good news is that there is likely to be a trickle of these university-taught developers and that this small stream is likely to continue for many years. It is my hope that the stream will grow as word spreads and as more professors adopt approaches involving students in open source projects.
One significant advantage in our efforts to make open source more prevalent on college campuses? The already-growing awareness of open source within the computing student population and beyond. Students are excited by participating in open source, no matter how it's introduced. Hopefully this excitement will catch fire in academia—in the classrooms and beyond.
11 Comments