OpenDaylight Developer Spotlight: Michal Polkorab

OpenDaylight is an active community of developers who are passionate about transforming networking. This blog series highlights the people who are collaborating to create the future of SDN and NFV.

I am a software developer at Pantheon Technologies - a consulting company based in Slovakia and heavily involved in OpenDaylight. I joined Pantheon in July 2013, shortly after I graduated from the Masaryk University in Brno, Czech Republic. Prior to joining Pantheon I had experience with some university projects and various smaller IT projects, ranging from object-oriented design through optimization tasks to various graphical works. Nowadays I keep improving myself in many fields including networking, documentation and communication. Everything I learn on a daily on a daily basis is pretty much thanks to the OpenDaylight community.

What project in OpenDaylight are you working on? Any new developments to share?
I am the lead developer on the OpenFlow Protocol Library (openflowjava) project. The library is an architectural component between OpenFlow Plugin and OpenFlow device. It ensures the communication with devices -- translating messages both from / to device and providing the connection abstraction for the OpenFlow Plugin. We have implemented support for the OpenFlow v1.0 and v1.3 over the TCP protocol. We have also finished our implementation regarding extensibility support. We are now starting to focus on the performance improvement, and we plan to add support for communication over Transport Layer Security and User Datagram protocols in the near future.

OpenDaylight’s first software release debuted in February 2014. What do you think is most important for the project to focus on for the next release?
I would say stability, performance and documentation. Stability was, in my opinion, something that was tough for us leading up to Hydrogen, because we were working so hard to get OpenDaylight’s first code release out. We’re making big improvements to the process to make this better for Helium. It’s important to be careful with what goes into repositories and check if it is not breaking other projects. Performance should be another goal. Now that we support the main functionality, we should start optimizing our code to achieve faster processing. And finally, documentation - the code should be documented as much as possible. These are areas we’re working on for the next release. Tutorial / introduction videos might help a lot, as we can help new developers that are lost in the code and don't know where to start.

Where do you see OpenDaylight in five years?
I hope that OpenDaylight will be used in majority of SDN solutions. Its support of multiple protocols makes OpenDaylight a really good candidate to achieve this goal. Openness brings tons of new, great ideas, which improves OpenDaylight even more. I also hope that OpenDaylight will become a huge meeting place where developers from different companies work together and share their knowledge to achieve common goals. Where they form new Proof-of-Concepts and advance into discovery of new technologies and approaches.

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

1. Check the existing documentation. First to get an overall picture and later to be able to start digging into the code.
2. Know your friends. ​It is very beneficial to know who is responsible for what part, so that you know who you can ask for help. Beginnings are always the tough part.
3. Don't be afraid! Don't be afraid to ask anything that is unclear. Don't be afraid to point out that something is missing in the documentation. Feel free to update it if you can (but get it reviewed). Don't be afraid to push your code, you have nothing to lose. Your code is always reviewed and can be always fixed / reversed if needed. New ideas are appreciated.

What is the best piece of developer advice you’ve ever received?
Actually, there are two great pieces of advice I was given:

1. Do you have test for that? You don't know if your code really works until you have tested it successfully.
2. Document it. You won't remember what you implemented after some time. Document it, so that you can always return to your ideas. You also help others to get involved when having proper documentation.