From the blog.

Managing Digital Racket
The more I tune out, the less I miss it. But that has presented me with some complex choices for a nuanced approach to curb
Complexity – My Friend, My Enemy
Over my years of network engineering, I've learned that the fewer features you can implement while still achieving a business goal, the better. Why? Fewer
no-fork

What Does It Mean When A Project Has Been Forked?

577 Words. Plan about 3 minute(s) to read this.

Open source projects that involve lots of folks sometimes run into conflicts. Should the project go in direction X, or direction Y? Is feature A more important, or feature B? And so on. Sometimes the concerns around an open source project are more pragmatic than pedantic. Should we, as a commercial entity, continue to use this open source project as is, or go in our own direction with it?

The keyword to look for in these circumstances is fork. If an open source project has been forked, the implication is often that someone picked up their marbles and gone to play somewhere else. I don’t mean to say that all forks are bad, but the term does have a certain tension with it. To quote Wikipedia,

…a project fork happens when developers take a copy of source code from one software package and start independent development on it, creating a distinct and separate piece of software. The term often implies not merely a development branch, but a split in the developer community, a form of schism.

I raise this issue as the good folks at Brocade want to be very sure that I (and you) understand that their Brocade SDN Controller is not a fork of the OpenDaylight Project. Lest I have led you astray in anything I have written — and I know I got it wrong once in the past — I want readers to be clear on this forking point.

For instance, I mentioned in this recent post,

So, what do I mean that the Brocade SDN Controller is “more or less” OpenDaylight? Well, ODL is a controller made up of several different projects. Brocade might not use every project that’s a part of the official ODL releases. And, it’s possible they’ll add some of their own projects that don’t end up as part of the ODL package. For example, in the 2.0 release announced on 15-September-2015, Brocade has deprecated the ODL-standard DLUX UI, replacing it with a custom Brocade-branded UI.

If you thought that meant “Brocade forked ODL,” it does not. One of my contacts at Brocade stated for maximum clarity,

Everything in our controller distro is from ODL (core article of faith), although not everything from ODL is in our distro. DLUX is one thing that is not in our distro with 2.0, although one could download and use that if desired. The Brocade UI is very explicitly technically separated from, though commercially bundled with, the controller distro (just like Topology Manager). Anything that is Brocade special sauce is developed separately from the core controller distro, because we have pledged to stay in synch with the Project—this is both a user expectation, and also the way we ensure that we can continue to leverage any and all aspects of the Project. Any proprietary extensions added to a distro will increasingly make that impossible over time. [Italics mine.]

I hope that dispels any confusion.

Now, lest this seem like a trivial matter, forking is one of those things to keep a close eye on as you investigate any of the several ODL-based controllers available today. If you go with an ODL-based controller, ideally it’s one that has not been forked, key long-term issues being SDN application portability and product upkeep. Use a forked ODL-based controller, increase your risk for vendor lock-in. Use an un-forked ODL-based controller, and minimize that risk.

Now stop giggling, and get on with your day. ;-)