Club Silencio

As many other already expressed on planet GNOME, I find Philip‘s post pretty disconcerting, especially since he mentions some of the projects I work on and that over the last years have seen many successful and rewarding contributions from OPW interns and GSOC students.

Our developer tools surely need more work to make them compelling, but that is achieved by forming a vision of how those should work, designing solutions to achieve that vision and contributing code to implement the design. Maybe Philip could blog about which amazing new patches he created for the projects he mentions or volunteer for mentoring some talented new contributor to work on those projects…

With that said, I think we should take the time consider how to make programs like OPW and GSOC even more successful and effective than what we have today. Here are a few ideas… I am not sure that all of them are good, as a matter of fact I can think of a few downsides to some of them, but I think they are at least worth discussing.

• Group projects: GSOC has a policy of  1 student : 1 project, that makes a lot of sense for administrative reasons, but I think it is pretty detrimental to the goal of involving new contributors. Working in a small group of 2 or 3 people on a project allows interns to learn to collaborate effectively, tackle more challenging problems and lighten the workload of mentors since I think many of the day to day problems can be overcome discussing within the team
• More flexible schedule and size: both GSOC and OPW have a well established cadence that also resonates with our release schedule. This has some obvious positve sides, but makes me wonder if there are negatives too… All proposed tasks must be of a reasonable size for the given period and we often have a hard time coming up with good proposals. I also wonder if we delay tackling some specific problem or idea that would benefit our users today, just because it may be a good internship project in the future
• Find a way to have more maintenance/implementation tasks: most of the tasks are “new features”, which sometimes leads to a strange inversion where we force inexperienced developers to struggle with architecture and API design while the time of the experienced developers goes into maintenance work and bugfixing. It would be great to find a way to let new contributors ramp up their experience and get familiar with the codebase and platform and at the same time have experienced developers work on advanced features without incurring in same the pitfalls over and over
• Alternative compensation: when I started contributing to gnome on my free time the main driving factors were the possibility to learn how real software worked, the possibility of making a difference creating something that other people use daily and the ability of scratching my own itches in the software I used. The original idea behind monetary compensation in GSOC was to be able to have some brilliant students work full time of free software during the summer instead of going flipping burgers and I do not think anyone can argue with the original idea, but we need to make sure we select contributors that are committed to working on gnome. How do we avoid frustrating contributors who do not get any money for their efforts? What if the reward was an internship in one of the sponsoring companies? Or some credits for the academic career? (Obviously this would require to have those organization on board with the idea)