Summer of Code: Halfway Through

Midterm evaluations begin today for Google's Summer of Code program, so what better time than now to reflect on the program so far? Here I hope to give some insight into my progress thus far, why it is thus, and where I feel I stand. This will inevitably provide a good idea of my impressions on open source up to this point, albeit indirectly.

Back at the end of May, the official program start, my plan was to write up a tutorial on how to use Eclipse on Windows to debug Inkscape, tackle a quick bug from a list my mentor provided, then move on to some of the work that was contained in my application proposal. I never expected to have that bug take me to the middle of the program. I am certainly not new to large software projects, so it has been interesting to experience such a steep learning curve.

Despite my relatively slow progress, I can say that I have learned much in the process. I have discovered both how some of Inkscape’s general architecture works, and the basic workings of the code that handles text. I feel very well equipped to tackle my next task with an efficiency and grace that would not have been possible had I jumped into it head first back in May.

More importantly, I have a genuine desire to stick around after the summer. There would be no sense in whipping up some fast and dirty code just to get paid by Google and then move on. Therefore, I try to look at the time spent thus far as an investment.

(By the way, the bug I’m referring to is really more of a small feature. I’m adding support for the tref element, as you may have read about in an earlier post about some frustrations encountered.)

There are several factors that I feel have hindered my progress. These are things that I have personally taken some time to get used to, not necessarily inherent flaws in the way Inkscape is built or managed. In fact, some of these issues are a direct result of working with Windows when the code is much better suited to development in Linux.

Builds Take Forever

Even if I change just one line of code, I have to wait ten minutes to rebuild the code. This is incredibly frustrating and a huge time waster. Often, I can’t move on to work on the next thing while waiting because I don’t know what the next thing is going to be before I try the code I am building for in the first place. Especially when just learning the code, I find myself needing to experiment with different one line changes constantly. Perhaps I wouldn’t need to do this so often if the next issue – debugging – were non-existent.

Debugging Stinks

Stepping through code, watching variables, breaking on assertions – this is the sort of thing that can really speed up the learning process for a new piece of software. I wasn’t too enthusiastic about debugging with gdb on the command line, so I very fortunately managed to set up Eclipse to debug using the CDT plugin. This essentially gives a GUI front end to gdb. (I’ll note that this took some fighting back in March when I was getting my Summer of Code application together. Others were also having a hard time setting it up; this is why I spent the first few days of the program writing a tutorial about it.)

Now, I don’t know if it’s gdb or simply Eclipse’s use of it, but debugging in this manner is very flaky. In debug mode, I can’t open files (though this has been proven to happen on the command line as well). Breakpoints often won’t work unless they are set before the application is launched. While stepping through code, the lines being executed seem to jump backwards a line or two unexpectedly. The debugger doesn’t break on crashes and can’t be arbitrarily suspended. Sometimes the application just doesn’t feel like launching. And these are just the issues I can remember!

Documentation is Thin

Not a big surprise here, though more up to date documentation would be nice. Assuming that I just haven’t been too dumb to find it. ;)

Online Communication Can Be Tricky

I have to admit that the fully online nature of the project has been difficult to adjust to. I tend to try to figure things out myself in the early stages of a new project. I find this to be a very effective philosophy and helps me learn the basics in a way that they will stick in my mind long-term. Still, there are times when a quick question to a team member can clear things up very quickly. The only problem is, when questions can only be asked online, asking isn’t always fast.

I’ve often preferred communication via the written word. It gives you an opportunity to think out what you want to say. However, there are times when sitting in front of a screen with another person is invaluable. If I don’t know the correct or recognizable terminology for something, for example, I can just point at the code instead of describe it. We can watch the behaviour of the running software at the same time and talk about it realtime. We can even sketch little diagrams to explain what we’re talking about. Some of this sort of thing can be done online, but it is impersonal and often cumbersome.

Another thing I really miss is weekly team meetings. Sure, they don’t seem so great while you are waiting for them to end, but hearing about other peoples’ problems and the technical discussion that often follows can be really beneficial. Some of this comes through in emails sent to the team, as it does in an online-only community, but you get something extra with in-person meetings it seems.

***

As with all things, it’s much easier to state what’s wrong than what’s right. There are some aspects of this kind of work that I really like. Working from home has its challenges, but it is darned nice to avoid the half hour commute to work in the morning. It’s also pretty amazing to see how well people can make friends online, without possibly ever meeting each other. There is a real sense of community.

I was fortunate enough to meet some developers in person at Libre Graphics Meeting, which made the comradery more real for me. I also try to make myself visible in the community, participating in pertinent mailing list discussions and helping users on the IRC channel.

Given all of this, where do I stand? I’m not sure how well I’ve performed compared to the other Summer of Code students in terms of actual code produced, but I have felt fairly productive in terms of learning. I’m hoping I will feel as fast the second half of the summer as I felt slow during the first half.

No matter what happens, if I can finish the summer with a prestigious Summer of Code t-shirt and a fun open source project to work on, I will be a happy programmer.