You’ve scrubbed your code, completed your patches, tested and tested again. So, now you are ready to open source your code, right? Maybe not. See, achieving open source success is more complex than that.
There are factors beyond code that you could—indeed should—be thinking about to maximize your open source project’s chances of success. These are “secrets” too many open source developers either overlook or underestimate, but that can have a major influence on whether your project will be noticed, supported or shared, regardless of how well it is coded.
Drawing on our experience from hundreds of open source project requests, we have come up with a list of five key “beyond code” tasks that can spell the difference between an open source project either stalling or “starring.” They are particularly relevant for any open source developer of company-originated projects but are worth thinking about wherever you sit in the open source community. Here are the five “secret” practices for open source project success:
1 – Secure Internal (and External) Support
As you plan and then build your project, be sure to talk about it with both your team and managers. After all, you want their support. This will also help you confirm that there isn’t another open source developer in the company has started a similar project, that management is willing to release the IP you generate and that you will not be releasing existing IP that your company wants to keep to itself. In addition, you should explain the implications of what you are building. Open source etiquette dictates that you actively maintain the project – throwing it “over the wall” in hopes that another developer will do the work is not only in poor form but also unlikely to happen. These “zombie” projects can reflect poorly on your company, as well as your own reputation. You should expect your open source project to take up some of your work time, and your manager needs to be okay with that.
After release, you will want external support and opportunities for collaboration, too. Your due diligence should extend to checking that you are not recreating work that already exists in the open source community. This may seem obvious, but failure to check for existing work is a common issue – and a potential waste of your time that can easily be avoided. If there is a similar source project solving similar problems, why not join that community, collaborate and contribute code to making that project better? Choosing this path represents the true spirit and intent of open source.
2 – Get Your Licensing Right
Open source licenses come in many flavors, with varying implications for the IP you develop and the ownership you maintain. You do not want to pick a license just because it is well known (Apache) or has an impressive pedigree (MIT). Instead, make a deliberate, considered choice.
Your license should allow your project to function well, both within your company and out in the wider open source ecosystem. When in doubt, talk with your company’s legal experts or look to resources like the TODO group or the Linux Foundation’s open source guide.
3 – Communicate, Communicate, Communicate
If you do not help people learn about your project, it will stay on the shelf unused. So, it is essential that you spend time on communication.
That should start with your open source code. Mark it with what we call “the three Cs:” copyright notices, a copying permission statement and properly annotated comments. This will allow new users to quickly understand what the project does and how it works. Make sure, too, that you include license, notice, readme and contributing, etc. files, and all the documentation users need to build, install and use the project. The files in your repository should also detail how to contact you (the maintainer), to flag a bug, request a new feature, etc., and who else they can reach if you are not available.
Then, there is the outward-facing aspect of communication, where you tell people about your project. You cannot just put it on GitHub and expect everyone to find it. You have to talk about it, write about it, and be willing to answer questions about it. Find out where your potential users and collaborators hang out and tell them your story. Then, create a presentation for conferences and meetups, as well as a lightning (five minute) version. At a minimum, make sure you have a punchy, 25-word distillation of what your project does and why people might want to use it at the ready for meetings, conferences or any other opportunities you might have to spread the word. If you find any of this hard to do, it is worth the struggle. If you cannot sum up your project’s worth succinctly, others will have even more trouble than you. Being able to narrate your project’s purpose to potential contributors will get them behind your open source movement and encourage collaboration.
4 – Take Care with Names
Project naming is often an afterthought, but a good name can speed adoption and a poor one can hold you up. For one thing, you want to make sure your project can be found among GitHub’s millions of projects. An obscure name or one with deliberate misspellings can be hard to find, throwing your project’s chances for success off the rails. A name that echoes your project’s value proposition can do the opposite. Unique, simple and sincere are good watchwords here.
Your company might also have naming guidelines that you need to follow, so get clear on those upfront and be sure not to tread on protected brands or copyrights. Keep names for projects and products distinct or you’ll risk confusing your collaborators and customers. Be mindful of what a name can promise, too – avoid using a name that hints at more than you are accomplishing. And try not to be too clever – puns might amuse insiders, but they are no use if they confuse or put others off.
Overall, be respectful of your project, your company and your community. It is easy to be insulting without intending to be. Before you go public with a name, check what it means in other languages or if it has alternative meanings or uses that some might find offensive. Do some research online and take the time to walk around and ask your colleagues what they think as well.
5 – Build Your Community
Bill Joy famously said:“…no matter who you are, most of the smartest people work for someone else.” That’s a big reason why open source projects excel, of course: great technologies are built by great communities of people irrespective of the badges they wear. It is your job as an open source developer to tap into your particular community and encourage its best people to join you. You do that by offering a compelling technical vision, and by following the first four steps outlined above. But you also need to consciously build your community of collaborators.
For example, it is important to be inclusive. Diversity in teams breeds creativity and helps you anticipate and solve problems faster. Make an effort to think beyond your company, cultural, language and gender borders, and make your project interesting to as many people as possible. Publishing a code of conduct can help in assuring potential contributors from diverse backgrounds that you welcome their engagement while also protecting your open source software. Having a way for potential collaborators to reach you — email, slack or other means — is also critical: do not overlook this, and then be responsive.
Be sure to keep your lines of communication open, too. Share project management with others so that the effort does not go dormant when you are away. Say “thank you” early and often to your community members. People may be volunteering their time, and the power of expressing gratitude for their contributions by simply saying “thank you” cannot be underestimated. Expressing appreciation for others’ hard work will create internal advocates for your open source program, adding to your open source success story.
Lastly, remember that collaborators can offer much more than code and software knowledge. They provide crucial help with documentation, proofreading, meeting organization, advocacy and more. This also gives a programmer or developer the opportunity to build out more of their “soft skills” apart from just writing source code day in and day out. So be sure to encourage and welcome offers in all of these areas as well.
For more “secrets” to open source success, check out Dawn Foster’s blogs on open source strategy and how to build a successful open source community.
Stay tuned to the Open Source Blog for more secrets to open source success, and be sure to follow us on Twitter (@vmwopensource).
