Student participation in open source projects (A professor's perspective)

No readers like this yet.
Participation text on a field

Opensource.com

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.

Download Free eBookAt 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.

Tags
User profile image.
Heidi Ellis is Professor and Chair of the Computer Science and Information Technology department at Western New England University. She has a long-time interest in computing education and has been supporting student participation in open source software since 2006.

11 Comments

Heidi, this is a great post. Thanks for sharing your thoughts and experience.

I would like to challenge you on one piece that you touched on, the career focus part.

<cite>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.</cite>

What if academia incorporated participation in open source with actually landing a career? In other words, is there any reason why students shouldn't contribute to gain experience and knowledge to add to their resume to land a good career.

I'm thinking about Google's Summer of Code or even a way where the academic recruiting offices could start to build the bridge between open source contributions and career finding.

This might even be a good topic for another post.

Hi Jason,

Good point! I know that students have definitely leveraged their open source experience to the positive when job hunting where the open source experience has been a draw on their resume. Unfortunately, I have also seen seniors drop out of open source participation after graduation to focus on job needs, especially if the company isn't as supportive of open source. What I am hoping happens is that these folks return to the open source world once they are established in their careers. I'm not sure how to support this transition from an academic standpoint.

Thank you for more thinking fodder!

>while academia is very planned and structured. The open source way emphasizes short-term optimization and taking immediate advantage of resources

The open source way takes the immediate advantage of resources, because otherwise you end up like academia - dragging on a project forever, too slow, never going to be completed, and design-wise, it tends to be overstructured. Or in laymans terms, the abstract thinking that Math and CompSci students are taught makes them needlessy reimplement already existing things, and adding redundant layers.
Ex.: Even in projects [ http://www.cs.waikato.ac.nz/~tcs/tmp/thething.html ] like this (that are only useful for teaching), you will notice that students tend to drive the number of classes (in a C++/Java impl. for ex.) almost ad absurdum that no professional coder would.

Oh, agreed. Academia is one of the slowest moving entities, perhaps only slightly better than government :-) One of the goals of involving students in open source projects is to try to use the practical and real-world approach in open source development to teach computing, rather than teaching computing concepts that will be used open source or industry. Let students learn by example, so to speak.

Heidi

I'm not clear that academia moves as slowly, certainly in as structured a way, as your article suggests--for better or worse, nowadays many academic institutions are much more chaotic than the picture you draw.
The rise of sessional instructors and other short-term teaching staff, along with budget uncertainties, pressures for relevance and innovation have led to a disintegration of the slow-paced "ivory tower" academic domain. Where I work I am constantly dealing with new sessionals dropped in at the last moment to courses that were barely decided on before the schedule was printed. Curricula shift constantly and are supplemented by classes whose topics are essentially instructor-defined on the fly, sometimes after a chat with students about their needs. Even back twenty years ago, I recall discussing with a professor my desire to take her Shakespeare class, but having taken the undergrad Shakespeare already (covering different plays) and thus being unable to get credit for it. She defined a special studies course for me with a focus on Hamlet and voila! I was able to take her Shakespeare. I remember the long Hamlet essay I wrote for her to this day.
Some of these developments are positive, others less so. Perhaps institutions vary in the degree to which they have become more fast-moving and flexible, as well as how far they have fallen towards instruction as piecework.

More comments, from the FLOSS community:

http://lwn.net/Articles/418368/#Comments

This is great information. I recently wrote about the benefit for open source involvement to students, and you highlighted a number of the difficulties that became clear after I posted my opinions.

A few notes:

>First, most students are focused primarily on their degree and then on getting a job.

From both an experience and hiring perspective, I think most students would find their time well spent if they participated in an open source project. Having code shipped (bugs logged, documentation authored, ...) in an open source project is a great resume addition, and any organization that fails to see the value in these efforts is not an organization with which you should seek employment.

>The pace of the two environments is also different.

This reminds me of a write up about "Dr. Tae" (The skateboarding, ex-physics professor). He's quoted <a href="http://www.chicagoreader.com/chicago/yung-tae-kim-tony-hawk-shred-game-physics/Content?oid=2699227">here</a>, describing learning to skateboard as a better educational model, "The school is the thing that's artificial and pathological," he [Tae] says. "The persistence and the dedication needed in skateboarding—that's what we need to be teaching. No one says to a toddler, 'You have ten weeks to walk, and if you can't, you get an F and you're not allowed to try to walk anymore.' It's absurd, right?"

The scheduling of our courses is probably a more difficult issue than merging open source and education, but I think your points and Tae's highlight that maybe one of the reasons that education is difficult to mesh with open source is because our educational techniques are overly constrained. Nonetheless, you highlight appropriate difficulties and reasonable paths to drive the effort forward (slowly, but surely). Again, great post, thank you.

I think you have start by creating some expectations about student involvement in open source projects. This includes expectations for the students, for their professors, and for the projects with which they may interact. We certainly read about various individuals who have come up with some idea on their own while in undergraduate school, developed it, then gone out into the real world to become successful. Often, it seems that these individuals abandoned the idea of getting a degree so that they could set up some start-up corporation. Not something one wants to promote in undergraduates.
Does academia have any sense of who the people are that contribute to open source projects worldwide? They are not unemployed, homeless people doing open source development out of some mindset of desperation. It's pretty obvious they don't expect to become rich from these activities.
They are people who are trying to grab some sense of contributing to society in an unselfish way, for something that is intellectually stimulating, allows them to form connections on a global scale, make friends around the world with like-minded people.
How different is this from analyzing why someone would ever become a college professor? It's obviously not for the riches.
The challenge for the college professor is to get a sense of what it is that a student might be working on, to see if this is intellectually valid. But compare this to exercises they might do in class to assess their skills, easily gradable but fade into obscurity once the grade is assigned.
One thing a student can get from open source is a way to permanently be able to point to some code in some project and say, "I did that."

<cite>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.</cite>

<p>Or, open source can see it as investment, just as they do when they provide support to others who who may not end up joining and participating in a project. Not everyone does. </p>

<p>But it makes sense as a long term investment because a generation of new programmers would have experience in open source culture, and thus be more likely to adopt it in a business at some point in the future. In fact, this could be the strategy that eventually would shift all software development over to open source as the primary, preferred method of software development.</p>

<em> I believe that our efforts involving students in open source projects will pay off for the open source community—in the long run </em>

Heidi I also hold this hope. As you know through your GNOME a11y participation, we at Project:Possibility were pleased that some USC and UCLA students worked on GNOME Caribou during the SS12 competitions last year. While the students are always excited to work on accessibility projects, the the code gets 'dumped' with an open source licence. We were keen to provide the opportunity to engage in a real open source project, for mutual benefit.

Ben Konrath, then Caribou lead, really step up to the plate and mentored them before, during and after. He lead them though a patch submission and Stormy Peters also provided them with contribution certificates. Both of these were designed to encourage them to participate more in FOSS community activity. Such participation is hard in a 2 day hack when you have no prior experience.

So the GNOME Caribou students won the competition finals and and presented at the CSUN accessibility conference in San Diego. Now they have gone their ways and none have stayed active in the GNOME a11y community.

However my hope is they will draw on a great memory that gave them new skills through the experience. Perhaps at some in the future, when the right opportunity presents itself, they will contribute to either an open source project or an a11y project. Hopefully they will choose GNOME a11y.

We may never know exactly.

I am aware of Project:Possibility the great effort that USC and UCLA students put into Caribou. I'm hoping that in the next few years we'll see some return on that effort, although I note that it may be difficult to connect recent efforts to motivation provided several years in the past. Simply having a larger body of folks participating in OSS would be one indication.

Good thoughts!

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.