Vyatta Core (VC) is one of my top fanboy loves. It provides a firewall/router based on Debian Linux but with an elegant configuration system modeled on Junos. Vyatta previously offered VC as a community edition of their commercial router (with somewhat reduced features and a lag time). Their strategy seems to have changed when Brocade took them over, and unfortunately, the project has withered on the vine. I think I can safely pronounce it dead:
- Around 21 June 2013, public git commits were stopped and moved to internal servers. Bug tracking seems to have been moved to internal servers as well.
- Since then there has been complete silence about roadmap of VC, even to the point that the roadmap page now gives an access denied error. Previously-available patches and discussions also now show access denied.
- The forums are full of spam and documentation has been neglected.
- Off-the-record sources in Brocade/Vyatta have confirmed the above, so the assumption must be that all future development will be on Vyatta Subscription Edition (VSE), with no further progress for VC.
The community has already mourned this loss and started seeking alternatives. And yet, a vibrant community feel still exists in a few places:
- Vyatta’s tweet stream still seems consist of approximately 50% retweets of users raving about how great the config system is and how the product solves their real world problems.
- When Ubiquiti‘s EdgeRouter Lite using EdgeOS (a fork of VC6.3 ported to 64-bit embedded MIPS) was released, its forums exploded with user activity. They grew so much in the first few weeks after release that I unsubscribed due to not being able to keep up with the message volume. Unfortunately, Ubiquiti have always done their development internally, releasing source code as tarballs rather than the preferred method of hosting public git repositories.
- Plenty of people (including me) are still deploying it in new environments. When I first encountered VC, I liked it so much that I recommended to a client to use it for all their virtual routing. We bought VSE and haven’t even used it, because VC does everything we need. I would be happy to keep paying for VSE just as a way to support the future development of VC.
- There are still some interesting threads cropping up in the forums.
- Contributors to the unofficial Vyatta wiki have already started plans for a fork.
Why has this happened to such a great product? I think it simply boils down to Brocade (and Vyatta prior to the acquisition) not understanding FLOSS (Free/Libre and Open Source Software) culture and how to run a successful FLOSS project. Simon Phipps just wrote about how hard it is for companies to migrate to FLOSS and do it well, and VC is the latest casualty in this. Red Hat is one of the few companies doing it consistently.
I think it’s several months too late for Brocade to fix this situation. As the above links show, many people have lost faith in Brocade to do the right thing with VC. But hypothetically speaking, what would be the best possible outcome?
- Brocade employs a full-time staff member as community advocate/liaison. (I hereby volunteer for this job. Contact me for rates. 🙂 They reverse their decision about public git repositories. They convince Ubiquiti to do likewise and work towards a common shared code base in the public git repos. Together they make a kick-butt Vyatta Core, which is used as the core of future VSE and EdgeOS releases. It becomes the Vyatta equivalent of Fedora to Red Hat’s RHEL, the OpenSUSE to SLES. Brocade accepts contributions from the community, and begins providing per-incident or support contract-based services for VC as well as VSE.
- Next best thing: Brocade cultivates some good contacts in the community and begins regular source code drops to enable community respins, forming a relationship akin to that between RHEL and CentOS. The community takes up the mantle of providing support on whatever the Open Source respin is called.
- The community forks from the latest available Vyatta Core, integrating Brocade and Ubiquiti code whenever possible. This would be the least desirable outcome, but I see it as the most likely, given how hard it is to change networking vendors from the community side.
Outcome 1 is obviously a bit pie in the sky from me. But there are sound reasons why Brocade should do it. Most significant of these is that the virtual routing space is a hot area at the moment, and making VC the go-to choice for virtual routing would give Brocade the jump on Juniper’s vSRX and Cisco’s CSR1000v (by undercutting them on price). Vyatta is modelled on the Junos style of configuration, so the learning curve for Juniper engineers would be trivial. And if people go to Brocade for their virtual routing, they’re more likely to go to them for their physical network and storage switching.
Furthermore, VC has huge mind share amongst the people who deploy it. The people I’ve met who use Vyatta love working with Vyatta. I love working with it. It has the potential to gain Brocade many extra customers and avocates, both paid and unpaid. (Hint to Brocade: reasonably-priced support for VC would get you a lot of customers that wouldn’t have otherwise paid for VSE.) Embracing the community is a great way to ensure that network/systems engineers who have the opportunity to influence decision makers will influence them towards Brocade.
Let’s hope it’s not too late, and that Brocade proves me wrong. It would be a shame to see such a great project die. (And I am serious about the offer to become their community advocate. Call me. 🙂