Originally posted as a guest blog on OpenDaylight.org by Maddison Long, Marketing Director at Inocybe Technologies.
As an open source software defined networking (OSSDN) platform made up of many components with features that address various networking use-cases, OpenDaylight can seem complex when you first engage with the platform. By nature, the complex makeup of any open source networking platform can seem daunting.
For a team unfamiliar with an open source software defined networking (OSSDN) platform made up of many components that provide features to address solve various networking use-cases, a certain amount of investigation and learning on the go are required.
When the Inocybe team first began to explore OpenDaylight, it took some time to fully understand the potential of different OpenDaylight features and see a more holistic view of the platform’s distribution and functionality.
This exercise also gave us a few ideas that are worth sharing with other users and developers before they dive head-first into using OpenDaylight. If you’re not a day-to-day OpenDaylight developer (for example, an end user), it can be very difficult to know which components are commercially-ready and which ones are still in an exploratory phase.
Fortunately, a growing number of quality management tools, best practices and development processes are available to make the path from development to deployment smoother and easier.
One current option is Component information that’s available through static code analytic reports in sonar.opendaylight.org. Among other things, the tool covers each component’s amount of coverage, and checks styles / Java best practices, technical depth and duplication. Although these static code analytics reports provide a lot of useful information around the coverage and quality of code, it is by no means a one-stop shop for determining the quality of the given components. End users will still need to determine the status of a specific feature or component before jumping in. They still might not know if these features meet expectations. Which led us to question just how good are specific features and components?
A second tool available to the community is Spectrometer, which provides statistics on community contribution. Knowing who is working on what in the community is important. Monitoring project activity or analytics is excellent information to reference, but you have to go deep. The quality of each respective component goes far beyond just the number of commits.
This is why, at last year’s OpenDaylight Summit, we launched the OpenDaylight Project Explorer as a way to view project/component statistics combined with a centralized view of the overall health of the community. Currently, the tool enables users to browse OpenDaylight components and bundles (including sub-features and sub-bundles), and automatically displays any component dependencies.
The ability to crawl OpenDaylight features and bundles is what makes the ODL Explorer unique within the ecosystem. Over the course of the year we have received a lot of feedback from the community and the conclusion is overwhelmingly clear: the community would like us to invest in making Spectrometer the OpenDaylight statistics tool. For that reason, we have decided to merge ODL Explorer with OpenDaylight’s existing Spectrometer tool.
There is still work to be done to improve OpenDaylight’s Spectrometer tool, including integration into sonar.opendaylight.org and including metrics on mailing lists. Ultimately, we are aiming for this tool be the one-stop shop for the community to accelerate approval of projects using feedback from user engagements. This means that companies would be able to declare which projects/components they’ve used with their customer engagement(s) and how well it worked, in addition to having the ability for end users to provide feedback through ratings.
To learn more about ODLExplorer and Spectrometer, be sure to register for year’s OpenDaylight Summit. Alexis de Talhouet of Inocybe and Stephen Kitt of RedHat will be discussing both in their talk on OpenDaylight Best Practices, Tuesday, September 27 at 10:40 a.m.