[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Osdc-edu-authors] Draft article: a professor's perpsective - the landscape of academic participation in open source projects



Heidi Ellis from Western New England College has a draft article up here, text also pasted below:

http://opensource.com/education/10/11/professors-perspective-landscape-academic-participation-open-source-projects

Comments welcome. Will try to get her accounts + list memberships set up soon so I don't have to be a go-between. :)

--Mel

----

I must start this with a huge "Thank you" to 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 as to the landscape 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 the 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 surrmountable. From my perspective of trying to do this over several years, some rocks in the river have appeared that make navigating the current of open source involvement trickier than it first appeared.

When two groups collaborate, they typically do so to accomplish some common goals or to work together to accomplish 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 certain knowledge and skill set.

More importantly, the goals of the groups in the collaboration between open source and academia differ. 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 for these future developers (I happen to agree). Adademia 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/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 (e.g., developer expertise, time, funding) as they appear. Resources can become available and disappear relatively quickly. Due to the fluid nature of participation, it is difficult to estimate long-range (one or more years) resource availability in the open source environment. This is not to say that open source projects do not do long-term planning, but that the development process is sufficiently flexible to be able to select among different paths to a long-term goal as new paths open up.

Academia is built around long-term optimization and allocating resources over time. Academics have a fairly fixed set of resources (e.g., time, instructors, students) which vary little over the long term (several to many years). In addition, academics operate under a series of constraints on those resources. Academia is bound by time constraints such as semester schedules and class hours. It is bound curricularly by syllabi, learning outcomes and grading. These things cannot typically be changed within a 3-4 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 very different. The open source environment tends to be fast-paced and less predictable (more intermittent?) as people have more or less time to contribute to projects over time. Academia has a much slower (some might say glacial) pace that has higher predictability due to the regularity of the academic schedule.

Note that class schedules are frequently created six to eight months before the term starts. In addition, curricula plans must include the 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 and changes in curricula are typically phased in one year at a time over four years.

Clearly there are some large differences in culture. But I think that open source/academic collaborations can work as there are also some strong commonalities between the groups. The open osurce and academic environments share a desire to "do something", to produce a product that people will use. Both groups have a love of learning and both groups are based on the precept that something (knowledge/software) should be accessible to everyone. Both groups have a desire to belong to a professional group, to be interacting with like professionals and participating in ongoing professional activity. And interestingly, I think both groups share a desire to be self-directed, to have control over what they do.

What have I learned? Lots!

Participation in open source definitely benefits students. I have observed students gaining lots of professional knowledge and experience and also forming professional networks through their participation in open source. Many students are motivated by participating on an open source project and they get a better understanding of why the content of those courses we made them take 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 participation in an open source project looks 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 and that with little effort, I could take advantage of these opportunities if I'm willing to abandon my "plan". For instance, with 2 days notice, she and I set up a Hack Share where we invited Sebastian Dziallas to come "hack live" 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, etc. However, it 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. The outcome was that by not having the time to plan, the Hack Share may have reached fewer people. But if I had to take the time to plan, the event might not have occured at all. So the trade-off is to reach fewer people in smaller ways. The conversations with Mel have caused me to be more considered in evaluating and better able to take advantage of opportunities that arise.

Academia needs to be sure to give back to the OSS community. One very real danger in student participation in OSS is for students to learn from the community, to gain from the community but not provide anything back to that community. This violates the open source way and could easily contribute to the break up of open source/academic collaborations. Professors must find a way to provide some 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, etc.

I believe that our efforts in involving students in open source projects will pay off for the open source community. However, I believe that many of these benefits will not be reaped for several to many years. I say this for several reasons. First, many students are focused first on getting 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 a year and perhaps longer after graduation, these folks may not have time to contribute to OSS.

Second, I believe that students will carry the banner for open osurce, but that it will take time for the idea to spread. Remember that students are not professionals and they are learning open source participation in addition to all their other classes. They typically will 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 by involving students in open source. And it will take them even longer to be able to change their own classes to include open source and longer still to have open source integrated across a curriculum.

These observations are both positive and negative for the open source community. The bad news is that there is not likely to be a huge influx of new open source developers coming from college students in the near future. The good news is that there is likely to be a trickle of such developers and that this small stream is likely to continue over several to many years. And hopefully, the stream will grow as word spreads and as more professors adopt approaches to involving students in open source projects. One significant benefit is the growing awareness of open source within the computing student population and beyond.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]