Posts on Cloud,DevOps, Citrix,VMware and others. Also tracking my Continuous learning from Wintel to open source and development.
Words and views are my own and do not reflect on my companies views.
Disclaimer: some of the links on this site are affiliate links, if you click on them and make a purchase, I make a commission.

Tuesday, March 10, 2015

OpenDaylight Developer Spotlight: Daniel Farrell [feedly]

The OpenDaylight community is comprised of leading technologists from around the globe who are working together to transform networking with open source. This blog series highlights the developers, users and researchers collaborating within OpenDaylight to build an open, common platform for SDN and NFV.

About Daniel Farrell

Daniel Farrell is a Software Engineer, recently upgraded from an intern, on Red Hat's SDN Team. He has been working on SDN-related projects since he entered the industry, which was right as SDN started to pick up speed. From a non-technical perspective, Daniel enjoys craft beer, biking, SCUBA diving and travel.

Which project in OpenDaylight are you working on? Any new developments to share?

I'm a committer on the OpenDaylight Integration Team, so that's where the majority of my effort goes. In Helium I mostly did performance work as a co-lead of the Performance and Tools sub-team, including creating WCBench.

Since the Lithium release cycle started I've been on a packaging and deployment binge. So far I've built a base OpenDaylight Docker image, an OpenDaylight RPM and an OpenDaylight Puppet module (all still under development, patches welcome!). My change from performance to deployment was driven by demand from users who want to consume OpenDaylight in repeatable, automated ways. For example, I'm currently working closely with upstream OpenStack folks to help OPNFV consume OpenDaylight+OpenStack for their reference architecture.

There's also a big push in the Integration Team to step up our Neutron integration efforts this release cycle. I've been asked to drive that work, so ODL+Neutron integration will increasingly be my focus for the foreseeable future.

Finally, there's my work on OpenDaylight's Q&A-style help site, ask.opendaylight.org. I'm currently the #1 user Karma-wise, but I'd love to see some other folks step up and take that title from me. :)

What advice would you give to someone just getting started in an open source project?

Building healthy open source communities is something I care deeply about and invest quite a bit of time into. Without getting into too much detail, here are some of my top tips:

As you learn about a project, refactor any poor documentation you run into. This is a low overhead way to move from a user to a contributor, and it's a task new community members are especially well suited for. As someone new to the project, you're the authority on what's clear and what's confusing, you're studying docs that experienced project members infrequently read, you're constantly testing docs as you walk through them. Switching from a passive consumption mindset to one that requires you to synthesize information and output it clearly will help you to learn the material more deeply.

Engage the community. Using OpenDaylight as an example, come hang out on our IRC channels, join our mailing lists, attend project meetings, subscribe to our Trello boards and follow the community leaders on Twitter. You'll start to get a feel for what we're working on and what we need help with. I strongly suspect you'll quickly spot a TODO that's relevant to your skills.

Start small. My first patch in OpenDaylight was a simple replacement of `which` with `command -v`. That taught me the contribution process for OpenDaylight, got me talking with community members and was the beginning of the trust-building process that eventually resulted in being given committer privileges. As an example of what not to do, I once talked to a person on ask.opendaylight.org who wanted to do a re-write of the MD-SAL as their first contribution. They hadn't worked with the project members at all. Even if they had managed to get working code, dropping a massive, previously unheard of patch on a project is a horrible way to get involved.

Do everything in the open. If you find yourself communicating directly with community members via non-public channels, you're probably doing something wrong. Open, logged communication documents decisions and makes them accessible to anyone who wants to contribute.

What's your favorite tech conference or event?

Any one I can go to for free! Generally, that implies one I'm speaking at.

My favorite thing about the conferences I've attended to so far has been meeting community members in-person who I had previously only worked with over the Internet. Since I'm most involved in OpenDaylight, that makes the OpenDaylight Summit and OpenDaylight Dev Design Forum very appealing.

When and how do you get your best coding done? At night listening to music? In the morning with a cup of coffee?

Historically, I've been among the most absurd of nighttime coders. I was actually nocturnal for a solid chunk of grad school. I'd work alone until 7AM, sleep six hours, go work in a lab with the robotics team I lead and repeat.

I'm trying to force myself to become more of a morning person, to better sync with the schedules of the community, but it's a struggle. I'm also trying to make sure I get eight hours of sleep, as the data overwhelmingly suggests it's healthy.

What does your workspace look like?

Probably the most interesting feature is that it's covered in locks and lock picks. I don't have anyone to sword fight while I wait on my code to compile or a `vagrant up`, so I pick locks.

Software-wise, it's mostly dedicated to shells and Vim sessions. I use a tiling windows manager called i3, which looks strange and draws a lot of questions from people who see my monitors.