Open letter to Cisco about DevNet

What I wanted to do today is, show you some of the challenges, My teams and I are having interacting with DevNet.

This is the developer portal, that you guys put up. To help ease teams like mine and find access to API documentation, software development tool kits, and both closed and open source code.

My perspective

I’m a CCIE. I have automated and some large data centers using a wide range of API’s. I’m not a great programmer, luckily I hire people who are. My software development teams and I are building our own application stacks.

They run and put on Amazon right now. Our goal is to make sure that they easily and automatically deploy onto UCS platforms. And Nexus 9000’s, 5000’s, 7000’s with cool open source projects like OpenStack and OpenDaylight get integrated with them.

Feedback – DevNet is impossible to use

I’m going to tell you something, that’s probably really hard to hear. It is near impossible, to use DevNet to find information that we need to be able to achieve our goal. I think that’s your goal, helping guys like us integrate our software with gear like yours.

Example – Finding SDK’s and API Docs

The first thing, a really easy example, a basic thing that you’d want to do or that you’d want a developer to help a team be able to accomplish, is find SDK, find API documentation, and find software development tool kit. To allow us to hook into your gear.

However when me or anyone from my teams attempt to navigate to through devnet to find API / SDK’s the default is to pop us to a product page that has nothing to do with software development.

Instead of having my first and easiest navigation option go to the software that I’ve already made the decision to go ahead and integrate, I get sent to a product page that is trying to influence me to buy a server.

I’m looking for the information of, how I can integrate it. Why another product pitch? It makes no sense, absolutely no sense.

The hardware is not important, the API and SDK’s are

I don’t care what hardware data sheets there are. It’s not important. I’m looking at programmatically integrated to my system.

Sorry if that’s very aggressive, but this is really, really frustrating. This feedback as I bring new developers into my team, they get me too. “You told me to integrate this stuff, but where is this stuff?” First question, where’s my SDK?

Normally what would happen, is I would go open up my local git clone and do a get/pull (this is a linked clone of a source code repository owned / hosted somwhere else). If found the SDK before, I normally wouldn’t navigate to a site to see an update. I would have that repo integrated not only with my my local dev setup, but it would also be integrated into any tooling that I have. (Listed as a dependency, and auto built by Jenkins)

An example of what to do – Insieme and Webex on Github

One place that I love to go is http://www.github.com/CiscoSystem. This place is where the the WebEx team and some of the guys from, NOSTG push a lot of information. Kyle and Mark put a lot of stuff here too on GitHub. This is a place where developers collaborate.

This allows me, as someone who is integrating applications on their stuff to go ahead and, not only through a web page, go ahead and see some interesting stuff.

Very specifically, a great example, the Insieme team. Mike, an awesome guy on that team, has posted some interesting SDK’s information for the Nexus 5000.

It’s easy for me to find. I could Google it. I could search for it on GitHub. I can do a lot of cool things, things that are important to me, in my software development work flow.

Nexus 9k API docs on Github

In this example I talk about Mike Cohen’s code for Nexus 9K. This is how it should be done. Example –

Over the years I’ve had to hack these stupid expect scripts and interactions with NetConf to do shut/no shuts and do network testing. You get 1,000, 2,000 nodes, and with four links each you’re going to have transceiver failure and cable failures all over the place.

You end up writing these scripts, to go ahead and exercise the network and start tests on either end. One, it takes forever. Two, it’s a giant pain in the rear, especially when you have to diverse platforms.

I was poking around, and I see, “Oh, wow, someone wrote some interesting code, which, if you look at it, goes in and provides a link test.” This is really, really cool. This is code that I can use. I can integrate it into my own stuff, my own operational procedures. Not so bad.

Use of Developer Toolchains for collaboration

As a developer, Git provides a set of the tools that are used to track, communicate and collaborate. We use this to answer questions like – “who the heck wrote this?” The first thing we would do was go ahead and check the log.

Who wrote this stuff? OK, I see Mike Cohen. I’ve got his email address.

I can even go so far as to see when he did it. OK, that was at the end of December, December 19th.

I can see exactly what was added each day. Now there’s a log for the entire repository, Mike from Nexus repository.

I can see that there’s another developer who was contributing early on to the repository.

I can see that if I need to get clarity or have a question about utilization of this code, I can ping Mike Cohen.

Collaborating on code via Pull Requests

Say I improve the code. I find something unique and novel that I can use in my own networks, but I’m not in the business of maintaining a small patch to this.

I can go ahead and make my patch. Then I can submit a pull request back to Mike. Mike just gets an email that says, “Hey, please merge this. I found this useful. Inspect the code, test it, validate it. If it’s good, merge it.”

That makes it something that all the community can use. I’m not in the business of maintaining these minor patches. They distract from the effectiveness of me and my team. I want to be able to submit that.

My experience trying to do this with the UCS SDK on Communities

I downloaded it from some community’s page. I don’t know who wrote it. I don’t know who to contact. I can extend it. I can keep that private. It’s a top down community. It doesn’t support the community development, that’s been really key to the growth of open source.

Collaboration between Manufacturer, Integrator and Customer in OpenSource

We saw a move of Open Source projects from SourceForge to GitHub. It’s been real. GitHub has allowed this interaction between us that’s key to our development collaboration on OpenStack and OpenDaylight, SDN controller.

My team is one use case. Our company is not huge, but not small. We do about a half billion in revenues, but we’re big enough that we’ve been contributing for OpenStack for two years now and OpenDaylight since mid 2013.

We can push code back. We can contribute into the community. Where we find things that support an unfair advantage market, a new secret sauce, things that support it, we can share the burden, we can be good stewards.

We collaborate with Cisco, with Red Hat, with IBM, with HP in the open domain. What I’m pointing out here is there is no method enabled within DevNet to support that collaboration.

Cisco DevNet needs to support that collaboration

There’s a huge opportunity to do that. I’m hoping you take that chance. It’s not about tools. It’s about the back-end. It’s about the collaboration in the community.

My Recommendations

Don’t point me to product.

If I’m already looking for software integration information, I have made my purchasing decision. Shoving product in my face just gets in the way of my job.

If I’m so frustrated where I can’t find the API documentation and, very specifically, SDK’s, as a developer. I’m going to go to the competition and try to find theirs. It’s all about the software integration, not the tin can that we wrap a CPU in. We call that a server, right?

Please, please consolidate information onto GitHub

In the open source domain right now it’s not only where we collaborate, but it’s a tool chain that allows us to collaborate. It is the standard for open source communication and collaboration.

Linus Torvald invented it for a reason. The guys at GitHub have been really doing a great job in enabling this innovative community. That breaks down the barriers between manufacturer, integrator, and customer.

Set up a IRC channel in this community

Every day OpenStack, OpenDaylight, my own internal development teams’ use IRC channel’s to collaborate. You can see all my teams up on the public open source channels. Get Cisco channel up there. Make it so it’s integrated with DevNet. It’s not that technically challenge. That’s a huge opportunity.

What you should take away from this

Fundamentally you need to communicate and collaborate. DevNet should not only be we can be pointed to the software but a tool to encourage that collaboration.

Make sure that we know very clearly who is maintaining that repo, that there’s someone dedicated to evaluating emerging pull requests. Use us as a tool.

There are a lot of people that use Cisco gear out there, Cisco routers, phones, servers. There’s a small number of people there that, for many, many years, have been writing code that configures it.

If you can enable DevNet to be what it can truly become, which is a collaboration point, integrated with the common open source collaboration tools and platforms, GitHub…Maybe I’m dreaming of this day ,when I don’t have to re-factor my code every three years.

You can really start to create that community. Frankly there are a lot of us that are just waiting for it to happen. I’m looking forward to you creating a conversation and seeing this become what it could be.

Please share this:

Google+

9 responses so far ↓

I seriously love the feedback. We’re totally aligned on wanting to create the developer experience you describe- meaning one that is integrated with the developer tools (like github) that developers actually use.

We’re on a major undertaking to overhaul/create Cisco’s developer program. This is harder than it seems for a number of reasons. It’s very much a journey, and we’re totally attacking this problem head on.

Step one was the Developer portal. There are many other things underway, including Sandbox, Communities, Hackathons, etc. (Hint: Make sure to bring your developers to Cisco Live San Francisco.)

One tip for navigating the site: Try clicking some of the “Explore: DevNet” buttons… especially just walk across the Content Types on the bottom. It should give you pointers to much of the documentation, downloads, code samples, etc. that are available.

Another tip: On the top black bar menu click on DevNet->DevNet Map. It should let you click through our portfolio and drill down to the pages you need.

Thanks for the post, Colin. We really appreciate it when customers take the time to give detailed feedback. Would you rather see devnet fixed or all of our SDK’s/technical interchange moved to github / stackoverflow type sites?

The feedback is great and very aligned with where we’re going, including integration with GitHub. It’s a big task to cover all of Cisco’s products/platforms, so it’s definitely a challenge to get what everybody wants up front. But, we’re up the challenge and we’re playing with different ways to navigate. We definitely have room for improvement, but here are some of the tools we put in place to help navigate:

1. The very first part of your video shows the big “DevNet: Explore” area in the main part of the page. I noticed that you didn’t click on that. What that does is filter the tiles below. If you go along the Content types right there, you can click on “Tools” “Docs” etc. to get right to some (not all) of the things you asked about. Please give it a try and let me know what you think. The goal of this is to help someone “Explore” as they are learning about what is available.

2. There is also an “API Map” section that you can click on the top of the front page. This expands the entire site in an ordered manner, and as you drill down you can get a lay of the land and the details of what’s available underneath.

[…] Open letter to Cisco about DevNet | OpenStack Nerd, CCIE, DevOps Junkie – I respect Colin McNamara a lot. If he is having problem and speaking out, then this is a serious problem. Cisco DevNet is a sub-website designed to bring developer resources into a single place. The internal diversity inside Cisco probably made this an inhumanly challenging task to get this far but perhaps it isn’t enough. Other technologies and vendors have constant interaction between vendors, developers, customers and it works. […]

I was unable to understand why cisco is hiring a fake candidate .on 28/7/2014 candidate named M.Swaroop was going to join the cisco with 4 years of experience on buid & release engineer dont encourage them find in which location of cisco he is going to be placed i think on whitefield location as i came to know better you dont encourage such guys.