Skip to content

Latest commit

 

History

History
121 lines (87 loc) · 4.87 KB

contributor-buy-in.md

File metadata and controls

121 lines (87 loc) · 4.87 KB
Raw

Contributor buy-in

Which strategies were successful to inspire potential contributors?

The goal is to collect strategies that open source evangelists trying to convert corporate developers to open source contributors can use.

Company internal strategies

  • Start with an experiment

  • Encourage open source contributions for projects that are used in experiments and hacking sessions to establish a new tech stack.

  • Encourage Inner Source methods for software development

  • Introduce the same tooling for in-house software development that are common in open source projects

  • Lowering the barriers for patches

    • Legal issues
    • Tooling issues
    • Process issues
    • Cultural barriers
      • Start with Inner Source
      • See innersourcecommons.org

  • Instead of moving on from projects on the edge of being abandoned help keep them alive by donating your time to it - in particular for those that your core business depends on.

  • "For projects you use in your central business you get to push them in the direction that benefits your use case."

  • Change the wording - instead of talking about locally maintained patches, talk about locally maintained forks of upstream projects that you carry the cost form maintenance for.

  • "Be specific about where visibility and credits for contributions go so people know where to look and where to point to.

  • Make it simple to contribute, remove barriers inside of your organisation.

  • Facilitate a shift in culture of your employer that supports and encourages open source upstream contributions.

  • Educate your employer about the origins of open source components - and where there's a need for helping hands, as well as about what it means if downstream users are not providing support.

  • Highlight contributors, emphasize their support, both upstream and downstream.

  • In a build or buy situation open source provides you with a build and buy outcome.

  • Highlight how open source contributions are beneficial for the business bottom line, e.g. by enabling developers to try a product released as an open source component to drive leads.

  • Raise awareness of business value of up stream contributions in the entire company.

  • Highlight costs of downstream forks.

Strategies that projects can employ to make contributions easier

  • Establish fast turnaround times for contributions: Quick feedback and review

  • Provide stories that explain how others converted their employer

  • Make contributions simple.

  • Make it easy to get involved.

  • Provide a very well defined process for how to get started and how to contribute.

  • Be nice to new contributors and provide a warm welcome.

  • Highlight contributors, emphasize their support, both upstream and downstream.

  • Provide getting started tasks that are easy and do have impact.

  • An active and friendly community will be more successful in attracting contributors.

Which arguments were successful to inspire potential contributors?

  • "You'll get feedback from great peers and experts in the field."

  • "You'll get cool free swag"

  • "You'll get better visibility, open source contributions do count on your CV"

  • "You'll get visibility outside of your corporate development team."

  • "Instead of waiting for others to fix your issue you can implement the features you need yourself and fix the bugs you encounter yourself and as a result move faster in providing value to your customers."

  • "Those bugs that annoy you - simply fix them."

  • "Those features you find missing for your use case - simply implement them."

  • "You'll learn a lot about how other projects are being run, what kind of build management, code quality tooling, test tooling and CI tooling they use"

  • "Work on what you want when you want where you want"

  • "It's a great oportunity for networking and meeting interesting people that you can learn from"

  • "Patches maintained upstream are cheaper than locally maintained patches - you don't have to re-apply (and potentially modify them) on each new ustrream release"

  • "Your fix gone upstream will remain present in future versions which makes maintenance easier."

  • "Not only maintenance cost will be shared - also development cost will be shared for new features."

  • "Speed up development of features you need by helping build them."

  • "You'll get the chance to contribute to the greater good by being part of something that is bigger than yourself"

  • "By fixing things upstream you will help others as well."

  • "You'll be in a good position to drive innovation"

  • "You'll gain influence in the project you use daily."

  • "You'll be able to gain more experience and get valuable feedback"

  • "Instead of keeping documentation in your own blog post, why not contribute a documentation patch and link to the accepted patch on your blog post adding validation to your publication."