Skip to main content

A Blueprint for Building the OpenContrail Community

By April 14, 2017Community

One of the initiatives I was asked to lead when I joined Juniper Networks late last year was to map out the plan for building a diverse, engaged developer community around the OpenContrail project. This blog post is a quick update on our progress.

TL;DR: Juniper is engaged with key users to push OpenContrail even further ahead of other technologies while mapping out the community engagement plan.

The purpose of this effort is to address a major need: The OpenContrail community can be improved. We can increase the corporate diversity of upstream developers, we can amplify the voice of users in the roadmapping process, and we can broaden the application use cases for the core technology. We can do all these things while maintaining the wide technological and production-readiness lead that OpenContrail has created over alternative technologies.

Oddly, OpenContrail has been resource challenged largely due to its successes. Here’s what I mean: OpenContrail is found in the world’s largest SDN deployments at the largest carriers. It is the most battle-hardened SDN in use at scale, and that’s why OpenContrail is the #1 in SDN for OpenStack. All this means that an incredible amount of engineering work went into features, fixes and improvements. As with all technology endeavors, compromises were made, and one of those compromises was community management.

Another reality is that OpenContrail began its life as Contrail, the proprietary creation of a startup by the same name that was acquired by Juniper Networks in 2012. It was open sourced under the Apache 2.0 license in 2013. Since then, Juniper and a few, key contributors outside the organization have focused on building the project.

These factors are starting to change. We are working diligently towards leveling up our game in enabling the project’s community. Here’s a quick rundown of what else Juniper is working on to make the OpenContrail community a place that encourages and empowers both upstream contributions and the voice of the user:

  • Hiring a dedicated community manager to drive community engagement and act as a dedicated conduit into Juniper
  • Hired a highly visible open source advocate and expert to drive strategy (yours truly)
  • Hired a dedicated team of open source developers to work on community-specific efforts, including:
    • 100% dedicated to open source with no responsibility for product feature delivery
    • Currently in the process of handing off packaging and container management from Contrail engineering
    • Re-factoring and cleaning up packages, containers and plugins to various other projects
    • Looking at contributing to and helping with acceptance of community-contributed code in OpenContrail
    • Committing code to other adjacent ecosystems (e.g., OpenStack-Helm, OpenStack, Kubernetes)
  • Working through logistical issues around how code is upstreamed

Most importantly, I have been actively talking to members of the community, gathering information on what has worked and what hasn’t and helping the Contrail team to craft a long-term open source and community building strategy. As I’m thinking about Juniper’s open source community strategy, I’m bringing in lessons learned from OpenStack, Project CoprHD and elsewhere.

The reality is that not all open source communities are built the same way. Not all of them succeed due to following a cookie cutter approach. Some open source projects need no formal community or foundation to succeed. MySQL comes to mind, which never had a foundation, but there are many others. In fact, the default for most open source projects is an informal community. Other open source projects are largely dominated by a single contributor with an ecosystem of secondary developers, like Puppet, Chef, MongoDB, Ceph and many others. In Ceph, for example, all of the top contributors are from RedHat. The issue isn’t that one company currently dominates the OpenContrail community. The issue is that we haven’t discovered what kind of community we want to be yet.

Early reactions to this game plan have been positive. Last week, I spent time with a major OpenContrail user, syncing up with key executives and engineers who lead that company’s internal cloud efforts. The purpose of that meeting was to bring them up to speed on all of the changes in the pipeline for the OpenContrail community. Reactions were favorable and engaging—precisely what you want when kicking off a community strategy. Amongst a variety of joint efforts we’re working on with OpenContrail, users are co-presenting at upcoming conferences and co-development in both OpenContrail and OpenStack-Helm.

Finding the “OpenContrail Way” is a journey. We are taking the first steps toward shaping what the community will look like, and those who participate will be part of the journey and help shape the future of OpenContrail. We want everyone who wants to participate to engage fully. Together, we will make OpenContrail better, improving processes for governance and upstream contributions while improving tools for packaging, containers, build/release, CI/CD and more.

Join us today, and together we’ll make the best open source SDN for carrier-grade performance even better. I’m here to help and make certain this community is what we all want for the future.