I’m Wei Liu, a graduate student who is pursuing his master’s degree from China. If you read posts on blog.xen.org from time to time, you might remember me. I was participant of Google Summer of Code 2011 and worked on “Virtio on Xen” project for Xen.org. It turned out that I managed to contribute my humble two cents to open source Xen during GSoC, so Citrix (the backing company of Xen.org) offered me an internship position in Cambridge, UK.
The internship is almost over, so I thought it would be nice to share my experience of GSoC, working for Xen platform team, what I’ve learned and what I’ve accomplished so far.
Talking about GSoC now seems weird, but the point is I never wrote about it last year after I finished my project, so it is worth mentioning it now. Further more, GSoC is the starting point when I started to seriously work for open source Xen, it will make a good beginning of my story.
I started to play with Xen back in late 2009 when I joined my lab in Wuhan University. Most of my time I wrote code ranging from user space tools, Linux kernel to the underlying hypervisor — Xen. However my code was never upstreamed because it was written for specific needs and research purpose. I was always hoping I could contribute my effort to open source Xen project, however small.
Then by chance I found Google Summer of Code and applied for Xen.org. Luckily my proposal stood out. I could work for Xen community, be instructed by experienced Xen developers and get paid by Google, that’s fascinating.
But a successful application was merely the beginning of the whole summer.
As an open source developer, the commitment to an open source project is more than just coding. Actually I didn’t write as much code as I expected — I spent almost 50% of time discussing on Xen development list. Writing code is easy, but writing code which can benefit a large community or may extend its life cycle beyond a coder’s professional commitment to a project is not that easy. I asked many stupid questions on the list, I spammed my mentor almost everyday (hey, Stefano, that’s you), and I re-wrote my patch many times before it was finally accepted.
The final outcomes of Virtio on Xen were, I helped debug some weird bugs when playing with upstream components, some code that was written for general purpose went in open source Xen, and a prototype of Virtio on Xen was up and running. Not as successful as I expected (or even a failure if I stick to my proposal), but I was happy I could be helpful to the whole community.
The lesson is that, for an open source developer, it is very important to know the community. One needs to learn the past, present and beyond of a project before he can seriously sum up his two cents. Another lesson is that, communication is far more important than one may imagine. Effective communication can help boost development of a project, while poor communication will likely to make people step on each others’ toes (ouch!).
Then that’s several months for my other stuffs, courses, lab projects, etc. I could only play with Xen from time to time. I prepared myself for my first ever abroad travel during that period.
After months’ of paperwork, I finally came to Cambridge at the end of November 2011. Then I joined Xen platform team starting from December 2011. It’s my pleasure to work with open source Xen developers on-site. I continued my work in virtualization networking: the only difference was that I switched from Virtio to Netback/Netfront of Xen. As Ian Campbell put it, my task was like building a tower from ground up. There were so many challenges to overcome, so many decisions to make, and so many benchmarks to run. I felt pressured. The pressure didn’t come from the company, but from myself. I wondered how far I could go. I also felt excited, just imagine a predator sees his prey. I always find it a privilege to work for things that you like. I like open source project and community, and I get it. 🙂
Compared to my wild imagination, a developer’s life is pretty boring. Sometimes I code a full day away, sometimes I don’t code at all and run benchmarks. Everybody can imagine this life. One of the most interesting things I can think of is that the “unintentional side effects” of my work actually go in faster — I fixed several glitches for user space tools, Linux kernel and hypervisor. To sum up my life as part of the Xen platform team: I discussed with the team, I developed several prototypes to demonstrate my ideas, I ran benchmarks, I picked the most reasonable one for public review, I received positive and negative feedback, then started another cycle of development. As the development went deeper, I started to tangle with various parameters, which required more and more benchmarks and coding. And on and on and on. This project is far from finished, there are always space for more improvements. If I have chance I would like to come back and continue.
Life is good here, simple and straight-forward. I learned a lot from the team. However small, some problems might never be solved by myself alone. I also learned how business can benefit from open source community, the story of community management and operation. I made many new friends here.
This is just too long for a blog post, so let me stop here. My journey with Xen goes well so far. I learn a lot, I get a lot, and I help the community. I hope that everyone can benefit from open source Xen, either as user, developer, researcher or any other roles you see fit.