So your company is going to release an internal project as open source. Are you ready for your new responsibilities? You could just throw the code up on a forge like GitHub or GitLab, but it’s unlikely to receive attention or provide much benefit to the company.
Open sourcing an internal project requires a lot of thought and work. Releasing a project as open source requires changes to the development, build, and release workflow. This is not about the code per se; it’s the processes and infrastructure that surround the code that make the project successful.
VM Brasseur discusses what you need to know and what to expect before you release your internal project.
VM (aka Vicky) Brasseur spent most of her time in the tech industry leading software development departments and teams and providing technical management and leadership consulting for small and medium businesses. Now she leverages nearly 30 years of free and open source software experience and a strong business background to advise companies about free and open source software, technology, community, business, and the intersections between them. Vicky is the proud winner of the Perl White Camel Award (2014) and the O’Reilly Open Source Award (2016) and is the author of Forge Your Future with Open Source, the first book to detail how to contribute to free and open source software projects. (Think of it as the missing manual on open source contributions and community participation.) She’s the vice president of the Open Source Initiative, a moderator and author for Opensource.com, and a frequent and popular speaker at free and open source conferences and events. She frequently blogs about free and open source software, business, and technical management.
©2018, O'Reilly Media, Inc. • (800) 889-8969 or (707) 827-7019 • Monday-Friday 7:30am-5pm PT • All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners. • firstname.lastname@example.org