The Google Summer of Code program is winding down now, and it’s finally time to take a deep breath and look around a bit. I’d like to try to share with the readers of this blog my experiences with the Summer of Code program, and also offer a little bit of insight for those who are interested in how the whole thing came together, from the beginning to now.
Though the program doesn’t officially end until the 21st, I leave on vacation tomorrow, so this will serve as my end of program reflection. This article is rather long, so for those uninterested in SoC, you may wanna mosey on along now. ;)
The application process
I was lucky that I already had a project I was working on that I wanted to continue on throughout the summer. I think only a hand full of other projects that were accepted were in this same boat. So for me, I was very fortunate that I had to ’sell myself’ a little less, as more than a few of the judges already knew me and my project. The hard part of course, was proving what exactly you planned to do with your grant. If you are already running a reasonably successful project, you have an up hill battle proving that you really need support, whether or not you actually do.
For me, it was a matter of splitting up the interests and tending towards the ones I thought would get me accepted. Ruport has always been a piece of software motivated by three things: my own personal interests, the interests of my commercial clients, and the needs of the community, with considerable overlap. Though I could have ‘double dipped’ this summer by working on the areas that overlapped between my work and my community involvement, I didn’t feel like that’d be the best use of the funds (and also feared that people would see that as exploitative).
So, for me, my application was for those things that were least likely to get the needed TLC without some sort of external support. These were for things like ActiveRecord/Rails integration, complex formatting, and some powerful data manipulations. These were things that people had requested time after time, and I had to turn down due to lack of resources. I had to assume that the judges would be looking for projects that met ‘real’ community needs, so this was what I tried to target with my applications.
When I look at the other projects that were accepted, I feel like this was a safe bet. Every single accepted project was either something that would be useful to a broad range of people, or *very* useful to a specific problem domain. Pragmatism seems to have won out in selections, and I think that this is essential considering the limited amount of grants available.
Waiting for an acceptance letter
The judging process is something I really feel could use a little more transparency. To get any feedback at all, you basically needed to wait for a judge to express interest in your project, and then try to get whatever information you could from them as far as your status in the program went. I don’t think this was a fault in the judging, but in the judging process. There was this obscure web application that both students and mentors needed to use that didn’t seem to promote openness. This was very much a ’sit and wait’ game, even if you had someone who was willing to share some information with you. It was scary to never know exactly how many applications would be accepted, and also what the selection criteria was. This I feel is mostly just the effects of a new program getting its sea legs, and not some major failure in any of the organizers.
I really feel that we might be able to enhance our experience as a community next year if we *immediately* get a ruby summer of code mailing list / IRC channel going, rather than waiting until after people are accepted. Maybe there was an effort like that this year? If there was, let’s try to make sure all applicants hear about it next year. I think this would do a lot to help people really prepare themselves for the program, and also allow the community as a whole to have a greater level of interaction with us.
I have to admit that all the waiting was worth it when I got my letter of acceptance, though :)
Getting into the groove
After we were accepted, it was more or less time to get down to business. This involved getting to know our mentors, making plans for milestones and scheduling meetings and the like. This to me was the most difficult transition. Basically, a project I was used to working on without any structure or formal planning would need to be turned into something that could be evaluated on a week to week basis, with a clear set of goals that would lead to successful completion of my project.
Being a fairly experienced rubyist and someone who has been writing free software for years, it was a little tough for me to get into this sort of production oriented groove. My mentor and I struggled to find the right relationship that’d be most beneficial, and because there were no real guidelines as to how a mentor *should* help their student, this was a non-trivial effort. After we found that balance, things started to go a lot more smoothly. I feel like this is an important part of the program, being on the same page with your mentor, and might even suggest that for next year, students should be asked to write a detailed explaination of what they need from a mentor for the summer. There are many students who were not super experienced when they entered this program, and many others whose experience may have exceeded that of their mentors. Obviously, these students have different needs, and getting them right is tricky.
To my mentor’s credit, I am impressed by the patience and willingness to work with me that he exhibited. Anyone who’s argued with me over something like say… software licensing… knows that I can be difficult at times. It was a good experience to sort of *need* to make a compromise, and I think that has been one of the best things that have happened in this program for me.
Keeping up with those Milestones
I am happy to say that I don’t think I ever fell more than 2 or 3 days behind schedule throughout the program. There are a few reasons for this, not the least of which being luck. Seriously though, I think this is where I may have had an advantage over some of the projects that were starting from scratch. (Perhaps Florian Groß had a similar experience here). Even though I was working on most of my summer of code stuff without relying on contributions, the design and debugging cycle was *much* easier with others to help lighten the load. Also, the effect of the software continuing to develop in other directions as well as the summer went on resulted in some really great growth. So, on more than one occasion, the Ruport community has been a real SoC life saver.
Another key to keeping on schedule was the intentional and possibly even excessive focus on keeping it simple. I don’t typically work in Rails day to day, and I also don’t have complex formatting needs. I wanted to provide the bare minimum where people would begin talking, and as the program winds down, I can easily say that this has been a great success. Instead of focusing on trying to get people to say ‘WOW, that feature is awesome!’, I tried to get all of the things I said I would get done to a point where people can say ‘Hey, I can work with that’. This was mostly to maintain broad community appeal, and only time will tell if it was a great approach. Still, I have to say that our community involvement has more than doubled since the start of this program, and that’s an indication to me that things seem to be going okay.
My mentor helped me here… he encouraged me to be sure to hit all of the milestones, even if it was just the basics. I feel like this will open the door for contribution greatly in the future.
Dealing With A Changing Community Face
One effect of improving any software project, and also getting any sort of publicity, is that things begin to change. When Ruport was a project I was working on in my spare time, I didn’t feel guilty saying “It’s easy to extend this! Just override method foo and insert a constant here”. The bottom line is, even though my software is still a tool designed for developers, it’s not going to be able to make the assumption that people will be willing to tear up its source to get things done. With the new, higher level features of this summer, I’ve noticed that my audience has shifted somewhat. This is another one of those things that took me a while to get used to. I’ve found myself having to learn more Rails this summer just to be able to help out my users.
This is a really interesting and exciting side effect of doing a long sprint on a free software project. Still, as a sort of cautionary word to those who haven’t thought about the effects of a changing community on their software, try to keep this in mind if you apply to continue development on a pet project of yours. Things *will* change, and this is just part of the free software evolution that I experienced for the first time this summer.
What I Really Didn’t Expect That I Wish I Planned For
1. Payments are *slow*
I suppose a should have anticipated this. 600+ participants all over the world, and millions of dollars needing to exchange hands. Some simple and honest advice: Do not count on SoC as your primary income source for the summer.
2. There are still kinks to be worked out
The Summer of Code program is only 2 years old. For some reason, I just sort of assumed that since it’s google, it has to work like magic (as much of their software does). What I didn’t really think about is how difficult it is to organize a program of this magnitude, and how much effort is involved in just keeping it all running. So it’s easy to become frustrated when something goes wrong, and harder to be understanding after you’re frustrated. For those entering this program next year, try to go in knowing that there is still a lot to learn about how to run this program smoothly, and try to be part of the constructive effort rather than those who just bring the program down with incessant negative comments.
3. It’s not a small commitment.
If you only have 5 or 10 hours a week to work for this program: Don’t join.
I saw a few of my close friends who were involved in this give up before the midterm because they realized they wouldn’t be able to meet their objectives. It’s *okay* if this happens, but it’d probably be better to be sure you’re ready to put in a lot of work before this starts.
If you are already working on a project, and you plan to use that, take your expected time commitment and double it. For those starting from scratch, this program is mostly a race to 0.1.0, a first working release. For developers working on an existing project, you still need to continue your duties of maintaining your software while you add in your new features, and if you’re like me, this might involve some major reworking of your existing codebase. Sure, the community will help you with this if you’ve attracted a userbase, but it’s no walk in the park. ;)
The three best things I got out of Google’s Summer of Code
1. Ruport’s community involvement has more than doubled.
Since I spent time focusing on feature requests rather than just extracting some code out of jobs I’ve done at work, each feature I added for SoC was making someone happy. After I made a couple people happy, it seemed like it had a snowball effect in that people started contributing ideas, code, criticism, and all the other things that make free software go round. I am amazed that more or less 24/7, I can hop into #ruport on freenode and find someone to chat with. I’m delighted to see Ruport finally being used in some real applications. I got involved in free software because I wanted to bring joy to people, and if I’ve done that for a few folks this summer, I feel like that’s a major win.
2. My software is now sitting on a more solid foundation
With more users, the shift from ‘worksforme’ to ‘works’ for any given feature is becoming increasingly important. Having more eyes on the code, and more mindshare available, I have greater confidence that we’re actually starting to build something useful. Hearing success stories has been motivating, and reports of problems or criticism of how we do this or that is helping to shape our project into something I’m proud to be a part of.
3. It’s really cool to say “I’m doing some work for google”
Seriously. That sounds really shallow and sort of useless, but it has actually been a major boost for me in a lot of ways. First of all, it’s great for impressing the non-techical ;) But in all seriousness, by me being able to say I am part of the Google Summer of Code program, it implies that Google, RubyCentral, and the awesome panel of judges who picked projects this year at least found my proposal interesting. As an undergraduate student, the completion of this program will likely to be my #1 Career accomplishment to date. This is something well worth the effort it took to get here.
That having been said, these 3 things are indeed in order ;)
One Thing I Regret
Because I was so busy with my own project, I’ve had very little opportunity to check out the other great projects that have been supported by this program. When I saw the list of projects accepted and the people involved in them, I really felt honoured to be a part of this. That sentiment hasn’t changed, and over the next few weeks I plan to try each and every one of the SoC projects, and maybe write an article here about them.
I wish I had made more time during the summer to keep in touch and say “Hey, keep up the good work” or something just small and supportive. Alas, there is always next year. ;)
If you would like to check out my Summer of Code project, Ruby Reports, you can start at the Ruport webpage, and you’ll probably find all the info you need to get started.