Is there a natural reason we have leveled off just shy of a dozen student projects? Is that all we really want done? All we are prepared to support?

The conclusion I’ve come to is that this is the level we get for the effort put in. Other projects that have more student slots simply have more people organizing as administrators, as well as mentors — more people making more smart decisions. They seem to be drawing from a common set of open roadmaps. Maybe the project-wide experience has made it so people actually watch out for opportunities to include students in the roadmap.

By contrast to what I’ve seen in Fedora, projects such as the Apache Software Foundation (ASF), GNOME, and KDE routinely have three to four times as many student slots. There are numerous reasons why, but I think a core part of it is this:

• The KDE project has a huge idea list this year – 120 as of this writing. Last year they got 46 student projects accepted to run for the summer.
• While GNOME’s page for this year is still a bit short as of this writing, they go through a vetting process for ideas and 2010′s idea page was 30 strong, well-organized ideas.
• Apache had 39 projects in 2010 and 32 in 2009, and some of them must have come from big project lists such as this list of 70+ project ideas in 2009.
• By contrast, Fedora’s idea page this year just grew to 20 items without organization. Past years are similar, such as thirty for 2010, fifteen for 2009, and thirty for 2008 all poured on to the page with a jumble of qualities. No vetting for quality and commitment of the mentors. Hard ground for much seed to get purchase.

So we have fewer ideas out there on average, and they are jumbled on the page with no organization against project wide goals or a roadmap.

What part do idea pages play?

From what I’ve seen, Google assigns student slots based on the interest students show in a project. More ideas, more coordinated marketing across the teams, and more work to get students’ attention generates more applications. That seems to be an important factor in determining how big a project can scale for students.

To make that attention happen requires commitment from each mentor and sub-project team they are associated with. To get a winning application, an idea might get three or four or ten that don’t quite make it. Mentors have to work fairly with all the students, trying to improve applications (within reason), and making decisions in the end to pick three dozen from an original of perhaps two or five hundred applications. Not much problem though when you’ve got a hundred mentors reviewing.

I reckon that a well organized and large pool of ideas comes about best when there are enough people working on making that happen. Subsequently, that becomes enough people to actually manage the increased program size, the applications, the mentoring, and so forth. Thus, the ideas page becomes a fair representation of how ready a project is to scale to what size.

If some folks in Fedora would really like to see our GSoC program be two-times, three-times, or even four-times the size that it has been, I put all this out there in hopes that it helps.

(Numbers in this post that are not linked back to the source originated from queries to Melanage at http://code.google.com/soc for the year specified in the statistic.)

Where are all those projects? Not on the Fedora ideas page.

Folks, check this out – your idea doesn’t have to be complete, or even contain much more than a few sketchy use cases. Sometimes you just need to spark an idea in the student, something to become passionate about.

If you aren’t sure if you can mentor, put your idea up anyway. If a strong student or three shows up, mentors can be found.

You may wonder why this matters so much to me? Quite simply, we missed our chance at being in last year’s Summer of Code because we didn’t have an ideas page.

I look at the page now, there are great ideas there, but not very many of them. I know that the Fedora Project and JBoss.org folks have many more ideas in them. A strong ideas page is an essential part of the application.

If you are interested in helping Fedora/JBoss.org to get in to this year’s Summer of Code, or want to help run the program after that, join up to the cross-project mentor list and ask what you can do.

And maybe it should be, or at least put in to suspended animation. Let me explain why I think this might be the right option, if the program doesn’t get what it needs.

So what does the program need?

More sponsors who provide budget and people.

People to collaborate openly with the community to make a professional event occur. Students get reimbursed for what amounts to three months of hackfest during their time-off-school, so it’s potentially more complicated than an ordinary open project and benefits from staff time of the sponsors.

Without these additional sponsors, I’m not sure it is worth our continued investment. In this case, the us is both the Fedora Project and Red Hat. Here’s my thinking about the whole picture.

The way my team at Red Hat works is pretty simple. We look for ways to make relatively minor investments – a portion of one or a very few people’s time + some budget – in ideas that affect the fabric of community and help projects we think have the potential for a higher return through open collaborations. That reward/return goes many directions, and some of it will splash back at Red Hat. A tiny bit, it’s an OK investment but maybe not worth as much as the ones that show a much bigger splash back at Red Hat. Bigger splashes also mean more goodness for everyone else because of Red Hat’s commitment to sustainable free software upstreams.

Last summer running Fedora Summer Coding (later renamed to “Fedora Students Contributing”) took a large investment of time and energy from me. So far, my efforts to find others to invest by providing more budget and/or assistance haven’t turned out very well. The best I’ve been able to do is take existing Fedora contributors and stretch them even thinner. That is not sustainable and it’s not providing a greater return splash for the investment.

What we accomplished last year was to get ten to twelve projects through the process. It is likely they would have been the projects we tried to get through Google Summer of Code, were we in that program. Our previous years had seen that many projects, so we were successful at getting an equivalent set of projects and mentors paired with students. That’s pretty great to pull together in a few short months.

But in the end it wasn’t any better than we did under Google’s program, with a lot more investment from Red Hat. So, from a Red Hat perspective, not really worth continuing if we can participate in the Summer of Code instead. Similarly, for Fedora we had a lot of community effort put in to running a program from scratch, much more work than if we’d been in Summer of Code in the first place. From a Fedora Project perspective, it makes more sense to put energy in to GSoC.

By comparison, other communities were able to pull the sponsoring money together, and do it with a  nice connection to an ecosystem of sponsoring companies who also use the open source code being worked on. For example, the Ruby Summer of Code looked good. They were able to put together ten times the funding pool than we did, and I reckon there were a few people who devoted some time to making the administration and project management work. Something to aspire to and a nice example of the summer coding model.

So we proved it could be done in Fedora and there are mentors and students and administrators willing to do some of the hard work. We took care of the need for mentors and students in getting projects done for 2010. If some other organizations with budget and people’s time are interested, we’re here to start talking about doing it again.

Meanwhile, we can take our efforts and put them in to running our program for Google Summer of Code.

In particular, Fedora’s GSoC team needs some people to work as program administrators, or “admins”.  It’s about taking responsibility for making sure we get ourselves together before, during the event, and in follow-up.  Otherwise, it’s not a ton of work, and it’s very rewarding to see improvements for the Fedora Project and students gaining greater experience participating in free and open source software.

Step one is to create, publicize, and help manage a wiki page of ideas for students.  You can look at the past year’s pages to see how to do it.

If you want to be involved in running the program, join the discussion group where much of this is organized and introduce yourself.  Old hands such as myself are available to help you make the magic happen.  You just have to be enthusiastic and interested.

For this coming year, if Fedora chooses to participate in the Google Summer of Code (and I think we should), I have decided that I am not going to be involved.

This is not complete abandonment.  In fact, this blog post is the first of potentially several that can be part of a package of mentoring-the-mentors as I pass on my mantle of leadership.

So if you care about the future of Fedora’s participation in Google Summer of Code (GSoC), for the love of all that you hold dear and then some beyond that, please read on.

There is always plenty of interest in bringing project ideas, being a mentor, and working as a student.  We’ve had some fair interest in the marketing and branding around the program. What is always a bit harder is getting enough administrators (admins).

Benefits of being an admin:

1. A great way to contribute to Fedora’s participation in a program that benefits Fedora and a number of students.
   • The student’s learn how to participate in free/open source software projects, where making mistakes and improving are as much a part of the project as getting the coding done.
   • Fedora has shown some great benefits from participation in this program, as I covered in this five-year round-up report.
2. Brief periods of activity, then you mostly get to watch the mentors and students do the real work.
3. If you are available, you are equally in the pool to attend the GSoC Mentor Summit should Fedora get invited.
4. You get the GSoC t-shirt and appreciation.
5. The web tools are fairly advanced by this time, so your work is much easier than “in the old days.”

Downsides of being an admin:

1. No downsides … unless someone else falls in a hole and you need to jump in to save them.  If a mentor disappears or has to go on vacation, you might have to fill in.  You need to be prepared to back-up everyone involved in whatever way they need.
2. Time: you have to keep up with the project, make sure mentors (especially) and students are getting everything in to Google on time.  It is a bit of project management and whip-cracking.
3. Money rides on the work, continuing participation in the program rides on it (for students all the way up to Fedora itself), sometimes our reputation rides on it.

There are several reasons I think this is the right time for me to step down from leading our GSoC participation:

1. If there is a Fedora Students Contributing next summer, I expect to be too busy with that to have any presence for GSoC.
2. Organization work needs to start immediately (or sooner), and I don’t have the breath to do it.  We need:
   1. A wiki page that lists project ideas from across the Fedora community.
   2. Some folks need to read the application requirements and put a schedule together to meet the deadlines.
   3. Work all the application process to completion.
3. Why start now? We didn’t last year, we got goals and methods confused, didn’t read the rules and schedule carefully, and ended up not getting a slot for Fedora and JBoss Comunity.  I take direct and personal responsibility for that; not just for the nobility of it (“O! I fall on my sword!“) but because I actually am responsible.  I probably suggested, and certainly promoted, the idea that we would hold-off on writing up random lists of project ideas until we’d organized better between the Fedora and JBoss community members.  As it happens, the list of project ideas was an application requirement (added the previous year.)  When you start making basic mistakes like, “Didn’t read the application requirements for changes from year-to-year,” it’s time to let some fresh eyes, thinking, and energy get involved.

Having freshness on these problems will be good for all involved.  Also, it’s a basic tenet of the open source way, turn over project leaders regularly.

This post is about the upcoming session for Fedora Students Contributing, to cover September 2010 to February 2011.

We need organizing help and we need sponsors.  In fact, would you like to help find new sponsors?

This week we’ll get the list of known tasks updated (in our Trac instance) for anyone to work on.

We have a success on our hands.  For a relatively small chunk of budget, we were able to fund about a dozen students to work on an equal number of interesting projects.  As you read more about this successful program in the coming weeks, think about how you can be involved.

Are you willing to recommend that an organization make a bet of a few thousand dollars in budget to find out what they can gain from supporting and helping organize the Fedora Students Contributing program?

Read some more.  Think about it.  Join the mailing list and introduce yourself.  Then, let’s get to work.

A quick look at the numbers:

• 15 students and projects.
• 20 primary mentors, with 15+ more general mentors (includes mentoring the mentors)
• Three funding sources (two from Red Hat) are making the proof of value program happen this summer:
  • We know the concept works (thanks Google’s Open Source Programs Office!), with specific value to Fedora Project and JBoss Community in this 5-year summary report.
  • We have a model to include other sponsors and are actively seeking them.
  • The work this summer proves to those potential sponsors the value of this program.
  • The sponsors who lay a wager by supporting the program for the southern hemisphere this October are buying their own proof of value to see if they want to continue next year.

Next on the schedule is the mid-term review.  During that period, mentors review and privately discuss the state of each project and the student.  The goal of a project is to help the student learn FOSS participation via the Fedora Project and JBoss Community. Ideally, there is good code or content that comes out of it, but completing the initial project plan isn’t the real purpose.  As often happens, in open development we discover new ideas, methods, and reasons along the way.

For example, this week I spoke with a mentor who’s student is struggling a bit with the initial scope of the project plan.  If the only goal were to get that coding done, we’d all be in trouble.  However, the mentor is going to work with the student to narrow the scope so that it is achievable within the schedule.

Having to rescope and reorganize is not uncommon in the FOSS worlds, and this student is learning that reality first hand.  We’re all ambitious with our ideas and skills, and sometimes don’t learn until immersed what is hard and what is easy.  It’s better to rescope and complete a smaller project than to leave in frustration.  Guiding the student in that way is what the mentor is here for, as much as anything else.

In terms of sponsoring, my goal is clear.  I want to see this program run the way we run free and open source software projects.  By bringing in other sponsors, we create more room for innovation in the program’s organization and implementation.  We give these friends and partners a chance to reap the same benefits with a similar investment.  In the process, we work together to strengthen the FOSS ecosystem in to higher education.

Guess what we call that?  Yeah, the open source way.

The announcement email explains everything nicely, with a list of accepted projects, and then details about funding.  We’re still working on updating and cleaning up the wiki pages.

The proposal review process was a challenge.  We missed our first deadline, then our second, and moved in to a few days where we just didn’t say anymore when things were going to be done until they were.  We finally reached a good set of decisions about which proposals to accept and fund.  In the end, we were six days late past the original deadline, and two days in to the actual student coding schedule.  I’ve proposed a minor adjustment to the schedule that puts the onus of making up the lost time on the mentors who lost it in the first place.

Part of this challenge was having to manually read, sort, and discuss proposals on the private mentor mailing list.  The proposals are all on the Fedora Project wiki, so managing and commenting was more difficult.  This was a result of starting the program from scratch without pre-building new infrastructure; in the future we’ll know more what we need by comparison to this experience.

I’m not having much success, and I think that’s as much about my weakness in this area as a lack of interest or budget.  I should get out the stacks of business cards I’ve collected from previous conferences, but cold calling people for money isn’t really my cup of tea.  Even when they might be interested, for real.  Even when it’s no big thing if they say no.  I’m just not so hot at it.

If you have any inclination or ability here, I’d appreciate help.  Finding sponsors and getting other people involved in the organization of the Summer Coding program has been the hardest part so far.  If we are going to continue to do it beyond this summer, we are going to need more help in organization, finding and working with sponsors, and so forth.

If you can help, please join us on the SIG mailing list and let us know what you think.

If you are in California this July and want to learn how to teach your students by working with codebases and collaborations from the real world, we invite you to join us and apply for POSSE California.  POSSE focuses on teaching educators how to be participants in open source projects, from tools to social rules.  This is done by actually contributing to a free and open source (FOSS) project during the course of the week long class.  The course is taught by instructors from Red Hat and the Open Source Initiative.  To learn more about the program, read the main POSSE page.