In my portion of the talk, I focused on the questions and challenges that might face someone attempting to start up an Open Source presence for their company.
The first thing you're faced with deciding is if you should start from the bottom up or the top down. Ultimately, you'll want the executive support from the top, but when you're just getting started you can function without it. Instead, find a good first project to be the poster child. Use this to build excitement and draw attention. Within your engineering team, it's very likely that most folks will be interested in Open Source and want to be involved. It's also just as likely that they'll have no idea how to do that. The poster child will serve as an example of not only how to do it, but that it is possible.
Start working on how to fit thinking about Open Source into the Software Development Life Cycle, for both outgoing open source and incoming open source software.
Find someone who will champion OSS for you, be that person, or share the role.
The percentage of folks who tell you they are interested in sharing their software is far greater than the percentage of folks who will put in the time to share it. Realizing this upfront will save you a lot of disappointment and undelivered work.
Figure out how to embed OSS into the DNA of your new projects. Learn the build systems that your developers use and make it easy for them to fork small, cohesive modules into open source ready projects that can be composed back into their larger, internal work. For example, break out small python libraries into pypi projects.
Straight Outta Compton
Open sourcing a software project successfully as a company is more than just creating amazing code. There no trivial amount of red tape to traverse from legal, to security, to IP. And after that there is promotion. Imagine if Eazy E had never met Jerry Heller. There might never have been an NWA as we know it or modern day rap. The role of the Open Source Office is to be the guide through all the red tape and promotional process to your developers that Jerry Heller was to NWA.
Success with OSS is a living thing and it needs to be tended to. It won't be on the roadmap for most teams and it won’t be a behavior for which time is allotted. In other words: it's unlikely that most developers will be gratuitously spending their time on OSS.
The role of the OSS office is to continually drive engagement within the company. Regularly promote successes in the community or within the company. Maybe you just got a great new hire because of an OSS project or maybe one of your engineers was just recognized in the tech news. Maybe a talented employee previously on the verge of leaving renewed their commitment to the company because of engagement with OSS. Share these successes with the whole engineering team or within the leadership group.
Make the time to meet with team managers to see what projects are coming up in their backlogs. Brainstorm how OSS could be a part of that.
Finally, it's critical to keep your community happy. Never release a project without thinking about promotion and adoption, easy install, good README, etc. Keep an eye on the metrics on your projects. Celebrate healthy projects. Respond to GitHub Issues in a timely manner. Encourage pull requests! Coach your developers to be polite, be thoughtful, and to engage with the community. Create mailing lists. Consider adopting a code of conduct. Be a responsible member of the OSS community and remember that as an enterprise / company, you are setting an example and representing more than simply your company.
These were the five points that I found most prominent from my time running Open Source at Box. However, the list of other reflections is much longer. Please see the presentation for some of the other takeaways from other members of the TODO Group. The role of Open Source Office is very critical to any company interested in being part of the OSS community, whether as a consumer or producer.