In my previous post, I talked about how networking was a large part of the discussion at the oVirt Kickoff Workshop. Increasingly, the network is elevating itself to be a first-class citizen in large open source infrastructure and cloud projects, including open source projects like OpenStack and now oVirt. In OpenStack, the Quantum project is the result of these discussions. Newborn community projects such as oVirt are starting to look at elevating the network to provide advanced functionality as well. It was no surprise a large portion of the last day of the workshop was spent on networking, with an early focus on Quantum.
The last day of the workshop started out the morning with an overview of SDNs and Quantum by Lew Tucker, CTO of Cloud at Cisco. Lew drew a nice overview of cloud networking on the white board, presenting an app-centric view of cloud and virtual networking. In the cloud network model, apps care only about connectivity to the network, not how that connectivity happens, thus the focus on apps as the center of this world.
Lew Tucker Diagraming Quantum Networking
After Lew was done, Dan Wendlandt, project lead for Quantum, presented his Quantum slides. This was helpful to level-set everyone at oVirt with regards to Quantum and OpenStack. One of the main pain points with looking at how Quantum can be shared from OpenStack into oVirt has been the difference in the networking models. OpenStack presents a very cloud-centric view of networking, whereas oVirt wants a more datacenter-centric model. Quantum was designed to generally be agnostic to the deployment model, so using it in oVirt should be a matter of fitting it into the architecture.
Ram Durairaj from Cisco, Chris Wright from Red Hat, and Dan Wendlandt from Nicira
After Dan was done giving a broad Quantum overview, Ram Durairaj from the Cisco OpenStack team presented on Quantum L3 Services. Currently, Quantum is designed to address the L2 abstraction of the network. Quantum L3 Services are meant to expose L3 concepts such as subnets and gateways into Quantum and the plugins. It would also allow for routing between tenant domains.
Ram Durairaj talking L3 Services
Now that the oVirt Kickoff Workshop is over, watching how the networking story with oVirt evolves will be interesting. The success of oVirt will be the result of the community around it, and the ecosystem for third party vendors it creates. With regards to networking in oVirt, the interactions between the Quantum community and the oVirt community have only just begun, and the future looks like a very collaborative affair between the two projects.
Tags: open source, oVirt, quantum, SDN
The formation of a new community in the Open Source world is an exciting time. We at Cisco were lucky enough to participate in the formation of one such community while hosting the oVirt Kickoff Workshop at our San Jose headquarters. In making the decision to Open Source their RHEV-M product, Red Hat also decided to create a community, and ultimately an ecosystem around oVirt. The workshop filled up early after being announced, and the presentations and discussions have given the new community a look at the assets Red Hat is placing under the oVirt umbrella.
One area generating a significant amount of discussion was the network. The discussion revolved around elevating the network as an equal to other components of oVirt. If this sounds familiar, it is because the exact same discussion was recently undertaken in the OpenStack project, the result of which is the Quantum project. Quantum is an attempt to create a standalone network service, capable of provisioning virtual and physical networks. In OpenStack, it works with Nova to create networks and bring up interfaces, attaching them to those networks. Given Quantum was created to be standalone, looking into how it could integrate with oVirt seems logical. Quantum has the potential to become a clear way to consolidate the handling of network topologies and overlays, both hardware and software, for OpenStack and oVirt. With it’s plug-in architecture, vendors can provide value with their hardware or software plug-ins, writing a single plug-in to enable their network technologies to work on both OpenStack and oVirt.
With one day left of the Workshop, the workshop will shift to BoF sessions, as well as roadmap and release scheduling. Cisco is excited to not only be a part of this community, but also to be a strategic partner with a board seat. Going forward, we hope the excitement level demonstrated at the workshop will carry over as the community drives to the initial release of oVirt.
Tags: OpenStack, oVirt, quantum
What if your mobile device allowed you the freedom to seamlessly roam across any network in the world, regardless of location or operator and with all the attributes you would expect, security or privacy… With LISPmob, we may have gotten a giant step closer as we open sourced a network stack for network mobility on Linux platforms, an implementation of basic LISP mobile node functionalities.
This is the Locator Identifier Separation Protocol, which supports the separation of the IPv4 and IPv6 address space following a network-based map-and-encapsulate scheme based on an IETF open standard.
We hope this will be a project and a community many will find not just interesting and vibrant, but necessary and fun to engage, collaborate and contribute.
How will this help your plans to deal with all these amazing possibilities of mobile access to an ever-growing Internet?
Tags: github, ietf, ipv4, ipv4 address exhaustion, IPv6, Linux, LISP, LISPmob, open source, open standards
I’ve been watching the ongoing schema.org battles over Microformats vs RDFa with some interest, not only because the underlying subject is interesting, but also because of some of the excellent quality of the discourse around how open communities function (or don’t as the case may be) that surround it.
Henri Sivonen has an excellent post on the Microformats vs RDFa… which also includes rather a lot of wise commentary about communities. One of the many things that jumped out at me was his description of the response to asking #whatwg for a proper spec for Microformats (so that he could write a validator):
The answer at the time was basically that if you want a proper spec, you should be the one doing the heavy lifting of writing one.
This attitude makes sense in a way. If you want to defend the community against detractors, you shouldn’t allow situations where a random commenter says something that’s cheap to the commenter to say but expensive for the community to address. Making the commenter put his money where his mouth is an effective way to weed out commenters who aren’t serious.
On the face of it, this would seem to be a very elementary observation. After all, it’s simply the age old formula of measuring how much something is valued by peoples willingness to sacrifice for it. In our normal cash-based economy, we do it all the time by trading our hard earned dollars for the effort of other people. But time and again, I see people missing this point. Coming into an open community and asking for something, without offering any sacrifice to re-enforce that interest.
Big companies are particularly bad about this, acustomed as they are to their simple expression of interest being seen as a precursor to business. But open communities aren’t in business in the traditional sense. There’s no good mechanism to directly express your interest to the community in dollars… that’s just not how it’s done (and honestly, that’s part of why the outcomes often work out so well, because you can’t simply buy them).
But *all* human interaction has it’s currency, and in the absence of dollars, often in open communities that currency is participation: contributing in kind what that community needs. In open standards communities, it can be working on a formal spec as in the example above. In an open source community it is most often contributing code, but can also be contributing other needful things (documentation, testing, etc).
So patch the change you want to see in the world… that’s the currency of Open
What change in an open community would you like to see, and what do you think you could contribute to encourage that change?
Ultimately, the health of an open source project is measured by the production of useful code, and the broad adoption of that code. This is easy to spot in many examples, projects like the Linux Kernel, Apache Tomcat, Samba, GNU gcc, etc are so useful, and have become so broadly adopted that they are literally the milieu in which the modern world is embedded.
It’s easy to spot the successes. And it’s also easy to notice that there are thriving communities collaborating around such successes. It’s much more interesting to ask what contributes to successful open source communities.
I would maintain, that successful open source communities lower the barriers to useful participation. They lower the activation energy for innovative activity. Some of the ways they do this are rather obvious, and some are less so.
Technical Barriers to participation:
- Is it easy to figure out where to get the source code?
- Is the code easily understandable to someone likely to be capable of contributing?
- Is it clear how to build the code?
- Can someone qualified to contribute easily figure out how to usefully modify the code?
- Is it clear and straightforward to contribute changes back upstream?
- And are all of these true even if you aren’t already part of the ‘in crowd’ for the project?
Social Barriers to participation:
- Is the community open to communication and participation from outsiders?
- Is it clear and obvious how to become part of the conversation around the development of the software? Is it easy?
- Can consumers get reasonable access to and attention from developers?
Legal Barriers to participation:
- Are you using a standard license ((L)GPL, Apache, BSD, etc)?
- Is your entire code base licensed under that license?
- Is it clear to contributors what license they must contribute under?
- Is it clear to consumers what license they are consuming under, and what they have to do to comply?
Evaluating Community Health:
The higher the barriers to collaboration a community raises, the harder it is for it to become successful. When starting an open source project, or evaluating whether to consume or contribute to one, it can be helpful to consider the barriers to participation, as early indicators of whether or not the project is likely to become or remain successful.
What other barriers to participation do you feel are important to be kept low for open source success?