Last weekend, I was fortunate enough to be able to attend the Midwest Open Source Software Conference (MOSSCon 2013). I met some fascinating people, listened to some great talks, and learned a bunch of new things.
All in all, a win.
I also presented a talk on two things:
- The general open source philosophy at Cisco
- My specific open source work at Cisco
The slides that I presented are below (slightly edited from their original form; I used a few animations in my original slides, which don’t work on Slideshare):
Hi Jeff,
Great presentation from what I can see, you always lose something with just the slides. I was wondering how you think Cisco will address Open Source with the pending purchase of Sourcefire. Sourcefire’s business model is substantially different than Cisco’s, as they have used Open Source as a tool to make them a defacto standard in IPS/IDS, and was able to upsell on ease of use, enterprise scalability, and support. This differs greatly from Cisco’s approach of selling proprietary products, and contributing to Open Source projects to assist and have a voice in future technology shifts.
I’m not involved in the Sourcefire acquisition, nor do I even have any knowledge of it (Cisco is a big company, after all), so I can’t comment on that directly. Nor do I really know anything about Sourcefire’s products, how they use open source, etc.
But from what you describe, I can say that those do not sound like opposite approaches to me.
Cisco includes a lot of open source code in our products. For example NXOS is the operating system that powers our Nexus line of switches. NXOS is based on Linux. Similarly, the baseboard management controllers (BMC) in our servers run an embedded flavor of Linux.
This is what I refer to as “standing on the shoulders of giants” in my slides.
In several of our products, we actively contribute back to the community — I cited several in the slides. Our level of contribution definitely does vary across projects, though, according to needs, resources, and practicality.
Keep in mind, too, that “contributing” can take many forms; it doesn’t always just mean directly submitting code. Contributing can be reporting bugs, too. For example, I know we ran into some Linux kernel bugs in the BMC code, and we’ve run into some Linux kernel bugs in my usNIC project. We dutifully reported these upstream — sometimes with code patches, sometimes without. These bugs eventually get fixed, and the state of the world is better after that.