If you’re interested in contributing to OPNFV, OpenDaylight or OpenStack, there are a few things to keep in mind to make the process easier.

Understanding the release cycle, making your first contributions count and considering the culture will go a long way. These were some of the takeaways from a discussion featuring Red Hat, OPNFV, OpenDaylight and OpenStack at the Linux Collaboration Summit.

Know the release cycle

If you don’t have any idea about the release cycle, missteps are easy to make.

For example, OpenStack has a six-month cadence, in the spring and fall. New features start with a specification (blueprint) that goes through a review and approval process. When the blueprint is approved, it’s targeted to a release and a milestone. New specifications won’t be discussed at least until feature freeze is reached in the third week of March and each OpenStack project will have its own schedule. OpenDaylight is on a similar six-month release timeline, said Luis Gomez, leader of the integration group in OpenDaylight. OPNFV is planning its first release in April, including platform, basic components and functional test, said Chris Price.

Plan strategically

“Think ahead and get your work in early,” said Chris Wright, technical director for software-defined networking at Red Hat. “Individual projects are resource constrained even if they are a reasonable additions.” Community members should advocate for what they think is important, but prioritize changes, keeping in mind future involvement and maintenance. “If we’re not showing up as developers, it’s not going to work.”

Take baby steps

You’ll generate more goodwill if you “don’t show up with code but start by reviewing code,” said Stefano Maffulli, developer advocate at OpenStack. Reviewers may already have a backlog of code to review, if you offer to take some of that work off their hands, you’re already helping rather than creating more work, he added.

If you’re joining the community because you need something specific, approach it with a community mindset.

“Focus on the feature and why it’s generally useful — and not just useful to telcos,” Wright said. Calling it an ‘NFV solution’ has some level of negative connotation, he added. “Be problem-statement focused, not problem-solution focused. Open it up to the community to find the best way to solve it.”

grxldaxc1zndp3rtej7q

Upstream first

Price put an emphasis on “upstream first,” adding that with OPNFV, the intention is not to fork project codes. Your best bet is to clearly communicate your requirements and collaborate on the dev side instead. The goal at OPNFV is to take customer requirements and turn them into relevant upstream development software projects.

Keeping these basic strategies in mind will help get everyone where they need to go.

Cross collaboration between OSS communities is a “top priority” to accelerate open source NFV implementation, Price added. Heather Kirksey of OPNFV, agreed. “We view ourselves as big tents for all open source projects around NFV.”

Cover Photo by Radio Saigon; Photo of OPNFV stickers from the conference by Nicole Martinelli. // CC BY NC