The shift toward open software defined networking (SDN) means more elements of networking hardware are now controlled by software. With increasing frequency, that software is open.
The changing landscape of interconnection isn't suited to the old, static client-server model, and networking isn't just about organizing and delivering data—it's about conversation and collaboration. Communities are a necessary, and extremely productive, part of SDN. They stimulate generative conversations, force us to be flexible and adaptable with our development routes, and give a sense of investment to each community member as they test, fix, and commit code.
I thought it would be helpful to give you some tips for creating open source communities to interact with your SDN or networking hardware. I've divided the tips into two sections: Attract and Maintain. After all, what's the use in building a community if it doesn't stick around?
Attract
Get yourself out there
When you're trying to attract people to your community, it's important to show them why your product is valuable and exciting. You can do this through a variety of means, but presentations at conventions and meetups are a great way to get a lot of eyes on what you're doing. If you can let them get their hands on it, even better.
Publicity always helps, but it's kind of a chicken and egg scenario (Which came first: The publicity or the community?). So make sure you're getting involved in other communities, as well. This way, you can show your interest in what other developers are doing, and give them a real person to tie to what you've been working on. Personability, transparency, and honesty are all important aspects of driving interest in what you've been developing. Plenty of people are eager to help a person fix bugs, but they might not be as interested in helping an impersonal logo.
Get the hardware out there
Ok, maybe not the hardware (that could get expensive), but try to offer at least a virtual image of the box or software as a relatively inexpensive way to get people developing against your platform. The idea is to get functionality in the hands of the (potential) community to garner interest and spur personal investment. Getting actual hardware in their hands is necessary at some point, but it isn't really scalable. Consider creating raw disk images that can get into whichever virtualization management structure they're using. And even if you aren't bringing the image yourself, you can provide a link to it that will allow interested parties to start building on it. Ease of access and streamlining of interaction are the most important factors at this stage, so consider supporting a variety of containers, e.g. docker and rkt (rocket).
Have documents ready
Everyone knows it's annoying to be asked the same question over and over again, so make sure you're providing a space for simple and clear instructions. Discussion boards, FAQs, and clear onboarding procedures will all save everyone the headache of running through the same points with each new member. If you can compile easy-to-read information about how to get started (Getting started with CloudRouter), it'll really help ease those new member pains. And once they're ready to start committing pull requests, make sure you've standardized that process. Most open source projects have gone to GitHub for pull request models. You can find ours here-CloudRouter pull requests—if you'd like to see how we approached it.
Interact with your community
Once you've established a group of people interested in working with you on what you're developing, make sure you don't fall off the map. Communities who encounter silence dissipate pretty quickly, so offering support is paramount when the community is small. As it grows it'll be more likely that community members will be able to help each other, but in the early stages you need to make sure you're there for them. Get on discussion boards, work with them, and just generally be proactive in the environment.
Maintain
Motivate contribution
This is a part of interacting with the community, but I put it here because maintaining interest in your product is really important; you can't get complacent once you attract members. There are plenty of ways to motivate members, but one good way is to offer challenges. This way, when you're particularly impressed by someone's skill or passion, you can reward them with the hardware we talked about earlier. It has to get in the hands of users at some point, so this not only reinvigorates the community, but allows you to target members who would interact with the hardware most productively. You can also keep members updated with email lists, blogs, and so on, but the big idea here is reciprocity—they're giving to you, so what are you giving to them? It's unwise to demand things from a community, but you should be able to steer them toward productive goals in an organic, collaborative way.
Compel diversity
Diversity is one of the toughest goals to attain in an open source community, but also one of the most valuable. Interested people frequently assume you're just looking for someone to code, and while coders are certainly important, so are people who can act as librarians or assist with documentation, testing, and validation. Open source is a meritocracy and importance is rightly attached to successful coding additions, but maybe we need to take a moment—either in forums or blogs—to appreciate the members who contribute to the less flashy aspects of the community. Librarians: Here's to you!
Foster positivity
Part of maintaining a community is welcoming new members. This might seem like it should be part of the "Attract" section above, but what I'm getting at is how to keep a community from being negative and insular. Assistance and a welcoming feel to the community means less fear of breaking into it, which, in turn, means more social possibilities.
There will always be parasites, and some people just want to be mean to appear superior, but the important thing is to deal with them quickly—they have to be ridden out. Usually you can allay the negativity by providing (or asking members to provide) clear and concise instructions and documentation, in order to cut down on the frustration evoked by entry-level questions, but it's also important to have a clear Code of Conduct like the one in our community section. Again, it's impossible to keep all the parasites away (just think of who would show up if you had a house party and left the doors wide open), but if you deal with it quickly the rest of the members can keep enjoying the party.
I've been working in open source for a long time, and these tips are what I've found most helpful when trying to build a community. If I were to try to summarize everything, I'd probably say, "Be open." I know that sounds simple, but it's what interconnection is all about. Just think about the word networking. It's about being open, meeting people, and exchanging information in order to create a more useful product.
Comments are closed.