Help your boss understand your upstream project

My previous posts on “open source first” have been more strategy than recipe. You need a clear, easy-to-understand plan in making the case for an upstream project to your manager. To help you with your boss, I have rewritten the “How to use Public Projects to Build Products” article into a list of 10 steps. These steps are comprehensive, covering strategy through implementation. A motivated developer, development manager or open-source director should lead these organizational changes over the many months it will take to implement them. I wish you success on your journey to better, stronger organization.

10 steps to supporting upstream projects

Strategy: When you set out your strategy and objectives for the year, highlight the open source projects you will be working with. This is important for recognizing the risks, dependencies and commitments you are making while working with the external engineering team that is the open source project.
Partners: Treat a public open source project like another engineering organization. If you are going to work with another engineering team, you expect to have a clear understanding of their responsibilities and timelines. You need to have the exact same expectations when working with a public open source project.
Individual contributors: Often, a developer will step forward with the desire to work on an open source project that is not part of the organization’s “plan.” This is exactly what the organization needs. Self motivated engineers are developing leadership skills. Allow the developer to allocate some of her/his time. Set responsibilities and timelines. This is just as much to protect the developer as is it is the company. Encourage open source contributions as technical social good efforts.
Fully support what you start: Middle management needs to make upper management aware of what the upstream open source work’s purpose is and why it’s important to supporting the overall development strategy. Never commit to an open source project that your organization is not willing to fully support.
Reviews: Annual developer performance reviews and headcount updates must include the upstream open source projects. This means that the development managers are ready to defend their open source developers with the facts of their work. Developers that excel at working with downstream and upstream development projects are the people who you want to recognize and promote. These developers are very often your best people and likely team leaders.
Products: Make sure your product managers understand how the public open source work contributes to delivering the product. In your private project management tool, establish an epic for each upstream open source project. Create stories for each upstream feature that is being worked on. Link each upstream feature to a product epic or story that a product manager is responsible for. The upstream developer needs to work with the product manager at least once every month, so that, as the upstream work progresses, there is a tight understanding of how that work will go into the product. A developer advocate like an open source director or development manager can be an alternative to work with the product manager.
Projects: Make sure the scrum master works with the upstream developer just like the rest of the downstream developers. The upstream stories need to be in the backlog along with the rest of the development work. It is likely the upstream schedule of delivering features is different from your downstream product. Adjust your stories for your backlog to match your downstream scrum schedule meaning that, if your downstream team is on a two-week sprint, make sure your upstream stories can also be delivered in that two-week sprint. Treat all of your developers equally for equal results.
Test, build, test, repeat: As the upstream work starts to take shape, get the code into a testable branch on your software pipeline. Make sure you have quality unit and build tests to verify the upstream work, so it can be more easily merged into your code base trunk when the time comes. Get members of your team to comment and help with the CI effort. As interest in what you are working on gets more help and visibility, you probably will get some public commits from your downstream development team.
Report: Track all your development work and report on progress. Highlight the upstream and downstream work as separate, but equal. Update leadership on the upstream project progress as much as the private development. Approach this as updating on the progress of a valued engineering partner.
Schedule: Keep up to date with the public projects release schedule and strategy. Internally, publish both your private release schedule alongside the public projects release schedule. Alignment of schedules is critical for success.

This post first appeared on Sean Robert’s blog. Roberts, director of platform product and open source at WalmartLabs, has been involved with OpenStack since 2012 holding various positions including board member and ambassador. Superuser is always interested in community content, email: editorATsuperuser.org.

Cover Photo // CC BY NC

Tags: Upstream