Isaac Sukin  | Mediacurrent Intern

Contact Author

This summer I was a mentor for the Google Summer of Code program for Drupal. I maintain the Facebook-style Statuses module, which allows users to have a stream of “status updates” on their user profiles and to write messages on other users’ profiles, like Facebook. So when I had the chance to mentor the Facebook-style Micropublisher proposal, which built on Facebook-style Statuses to allow attaching images, links, and video to status updates, I jumped on it.

The result was a resounding success, and I learned a lot during the process. Nitin Gupta, the student driving the project (and better known to some as publicmind) was an extraordinary developer in the true Drupal spirit. He gracefully put up with my pickiness about coding style, thoroughly researched the best code architecture for our purposes, and even identified places where Facebook-style Statuses itself could become more flexible. I truly believe that Nitin will remain committed to the module he created, and that both of us are better Drupal developers as a result of this process.

The Background

Long before the 2010 Google Summer of Code (GSoC) process began, I identified two major areas where Facebook-style Statuses (FBSS) could be improved. The first was abstracting status updates from users to allow creative solutions like FBSS as a replacement for the core comment module or status streams attached to Organic Groups. (Actually, although I had long thought about Organic Groups integration, that level of abstraction was Michelle Cox’s idea.) That effort is currently underway in the form of a new Facebook-style Statuses 3.x branch, since it requires rewriting thousands of lines of code and significant changes to the API and database schema.  

The second was attaching data to status updates – links, images, and video, but also audio, files, or anything else within reason. I wanted an extensible system held to very strict stylistic and architectural standards, but I knew that this would also require thousands of lines of code, and I didn’t have the resources in time or funding to get started.

Then Thomas Cermak contacted Nitin and me in February to discuss building out this second feature, which we eventually dubbed the “Micropublisher.” Nitin had first worked with FBSS in September 2009 when he had contacted me to ask about how to make some changes to it for a now-deprecated Facebook-style Links extension. At that point he didn’t even know what hook_form_alter() was, although he was a capable programmer outside of Drupal. Now Nitin was to take on the bulk of the work for this new, complex initiative because of my lack of time. We discussed and settled on an outline for development, and then on March 24th Nitin realized that the recently announced GSoC 2010 would be a perfect opportunity to gain support and exposure for the project. He submitted it and invited me to be a mentor, and real development work began soon afterwards.

The Process

Nitin’s skills were immediately apparent. I had an email (or six) from him nearly every day for the first month alone, in addition to commit notifications from the SVN repository where we developed until the project moved to the CVS repository on drupal.org. I reviewed Nitin’s commits every day and gave feedback. We often discussed the best way to implement various features and sometimes I explained new techniques, but usually I just had a list of places where Nitin had neglected to insert whitespace in control structures as recommended by Drupal’s coding standards.

I never had to say “rewrite this part, that code is unreadable…”

That is to say that Nitin made my job as mentor much easier than it could have been. I never had to say “rewrite this part, that code is unreadable” because Nitin researched everything before he acted, although I did try to ask “why did you do that this way?” frequently. I had a list of tasks I wanted Nitin to complete, and he was ticking them off faster than I had anticipated. By mid-June, the fundamentals of the new Facebook-style Micropublisher module, or FBSMP, were stable enough that I could preview its awesomeness in a presentation at Drupalcamp South Carolina / SouthEast LinuxFest.

In late June and early July, Nitin took a vacation, having graduated from the prestigious Indian Institute of Technology at Guwahati. This made me nervous. After a prolonged period of frequent communication, we were communicating much less frequently, right in the middle of when most GSoC students are at their most active. The fault was mostly mine; I neglected to check up as often as I should have because it was not something I had had to consciously think about before. It was just something we did. This was also when we transitioned to using Drupal.org for version control, so I wasn’t receiving commit notices any more from the SVN repository, which made it harder to keep up with and review changes.

It turned out that I had no need to worry, because Nitin stayed on task and completed everything we had planned. In the end, I was the one who was unable to do everything I had promised, because I didn’t keep track of the GSoC schedule and inadvertently planned a trip to Italy two weeks before it ended. Luckily Nitin had progressed so far by that point that it hardly mattered, and I’m extremely pleased with the end result.

Advice for Future Mentors

1. Explicitly schedule time at least twice a week to catch up with your student and discuss his or her progress. The more real-time it can be, the better; email is great for expressing complex ideas precisely, but in-person meetings, phone calls, and IRC chatting are better for hashing out problems and getting things done. Unfortunately, because Nitin is in India and I am in the United States, we weren’t able to talk in real time very often.
2. Choose a project that really excites you. If you are not personally invested in the outcome of the project, it can be difficult to fulfill your end of the deal; you will prioritize daily work-related tasks over reviewing your student’s code, and neither of you will benefit as a result. Since Nitin’s work directly enhanced the value of my own work – and because it achieved one of my two main goals for FBSS – I was very interested in making sure the project not only succeeded, but also met a strict set of goals and standards.
3. Outline your mutual goals with your student before you begin development, including how and when you plan to accomplish them. Some developers embrace chaos, and that’s fine in some cases, but as a team you need to be able to hold each other accountable. Be realistic, and schedule in time to make mistakes. Before Nitin and I started, I created an outline of the features I wanted completed and the standards by which I wanted them coded. Despite this, I made sure to leave room for flexibility and innovation – too tight a leash wouldn’t have let either of us learn anything.
4. Clearly establish what role each of you will play. From the beginning, I made it clear that I wouldn’t have time to participate in much of the actual programming, but that I would be setting most of the strategy and reviewing the code as often as possible. Although my contribution on the second point slowly declined over the summer, I think that my approach helped Nitin learn a lot about problem-solving and Drupal.
5. Write down due dates! I didn’t put them on my calendar, and as a result I ran out of time to do a final, overall review of the module before GSoC officially ended.
6. The process doesn’t end when the summer is over. Make sure that both you and the student understand that you will have some amount of responsibility to maintain your creation. Have a plan for what will happen when GSoC ends; for example, FBSMP will be folded into FBSS soon after the upcoming FBSS 6.3.x branch is upgraded to Drupal 7.

The Result

To be honest, I wasn’t sure what we were trying to accomplish could be done in a summer – but I am happy to say I was very wrong. I can now say that Drupal has a full Facebook-style Micropublisher, complete with link, image, and video attachments (as well as a thorough API, an extensible plugin system, and documentation for everything). You can see for yourself how cool this is on the demo I set up for the two presentations I’ve given on Social Networking in Drupal. (It’s now possible to build full-featured microblogging platforms like Twitter and Facebook in Drupal!)

It’s now possible to build full-featured microblogging platforms like Twitter and Facebook in Drupal!

Nitin was a pleasure to work with, and I look forward to continuing to work with him as we transition FBSMP to a central part of FBSS in Drupal 7. It is very clear how much he learned about Drupal, and I commend him on his ability to soak up information and come up with creative solutions. I am happy to say that Nitin also seems to have adopted Drupal’s coding style rules as a result of my incessant demands! I’m quite sure that he will continue to be a valuable contributor to Drupal’s ecosystem in the future.

As for me, I learned a lot about remote project management, and I also learned some valuable lessons from a number of times when Nitin asked for changes to the FBSS API to make FBSMP development easier. I had never actually had a reason to use my own API in the wild before, since I could just change the source if I needed to. It was fascinating to see my successes and failures in predicting how the API would need to be used.

There’s still quite a lot to be done. There are some inconsistencies in FBSMP that should be worked out, a CTools dependency that can probably be removed, some potential UI improvements, and of course the port to Drupal 7. But for a single summer’s work, I couldn’t be happier.