On Tue, Feb 23, 2010 at 05:47:38PM -0600, Patrick W. Barnes wrote:
Although I'm in violent agreement with Patrick here, there is one
part where I want to offer some additional thinking.
* Engaging students for long-term participation in FOSS
I would much rather introduce someone new to FOSS and endear our ways to them
than pad the wallet of an experienced contributor. That is the purpose of the
GSoC, and of my participation. If anyone gets a job or finds a way to profit
from their participation, that is awesome, but it is not the driving goal.
I agree that getting students participating in FOSS and learning how
to work in large codebases with a larger team was the specific Google
goal from the start, and it remains an important part. There has been
some evolution, though, on the part of Google and of participating
organizations. Google never forbade students already working within a
project from participating in GSoC with that project, so although not
encouraged it is allowed. Over the last few years, I feel there has
been a shift where it is recognized that it is useful and possibly
important to have some portion of the students be existing in the
community. To some degree, it is now encouraged.
For example, I've been hearing from other mentors e.g. at the Mentor
Summit that there are several reasons for working with existing
community members who are students. I heard back from Toshio and
Yaakov this last time, and it sounded as if the same sentiments were
held by the umbrella communities they spoke with.
* Students who are in the community but on the periphery and who
haven't found a way to make a solid contribution are using GSoC as
their bridge. The standard way of contributing by figuring things
out for one's self is an actual barrier for many people, who spend
some time at the fringes or go away and never return. GSoC gives
these folks a visible pathway to follow to participate in the
project, where the project's pathways hadn't been working (or
found.)
* Projects from people who are already familiar with the community are
more successful, having greater impact for the wider project. This
is partially because these students know from the inside what the
mentoring project needs. For Fedora in particular, where there is
an ongoing need for contributor-focused applications, it's very hard
for an outside person to figure out and navigate these needs.
* Students who are already experienced in the community or were
previously in GSoC are helpful to other students, both in attracting
them to make proposals, and in working with them afterward. They
are useful ambassadors to find, engage with totally new students,
and bring them to both GSoC and the project overall.
Students use their peer community to navigate the projects, and when
all students are new to the project, that peer community is less
able to help itself. Some topics will only be discussed amongst
peers, such as how the project is treating the students. A lesser
peer community means there is some content that never gets
addressed. For some students, this could be the simple difference
between success and failure.
There are always people at different levels in a community. Having
a group that is all new and no experience striations is not typical
of the real world outside of academia, and I think frankly hasn't
worked out as well in GSoC because of that. It was a flaw in the
original design - a student group can't all be 100% new, even if you
have 3 mentors to assigned to each student.
In other words, the "pure student vessel waiting to be filled with
our good community knowledge" is nice in the individual, but not as
great in the aggregate. I think the GSoC model was made to break up
the aggregate to gain access to that individual -- it's part of why
students are not allowed to work with other students on projects.
We should take care not to recreate the aggregate by insisting that
the student population fit a newbie-only model.
My take away from this is that we need to:
1. Do more to reach out to existing community members who are students
and let them know they can participate in GSoC; encouage them to
use it as a chance to resolve a big problem or implement a new
feature for the project.
2. Make sure that we maintain a strong balance of totally new
students; maybe 70% is a good target not to fall under?
3. Don't make hard and fast rules around this; we need to give mentors
and admins the flexibility to get students who are going to do
stuff with the time mentors give them. (Gaining participation
experience is a top priority, but as a project we cannot have that
be the sole outcome of all of our efforts. I can take the same
time I put in to one student and split it amongst 25 random people
and get a lot more new participants in FOSS.)
4. Don't play up the money aspect for any students; that's not the
goal of the effort, it's just a means to the goal. If a student is
focused on the money, they are probably the wrong student for
working in a community FOSS project.
How does that sound?
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri:
http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41