Some potentially useful advice below. Remember to apply it to all the software you use, including operating systems on local machines, company infrastructure, t

Some potentially useful advice below. Remember to apply it to all the software you use, including operating systems on local machines, company infrastructure, things you deploy in the cloud etc. Possibly your team has added workarounds and technical debt to your codebase for issues in your dependencies, that is probably a good place for them to start. It is also nice to give back to projects by working on "papercuts"; things that are easy to fix but annoy lots of people (Ubuntu did this for eg). Working on bigger stuff is good too, like fixing all crashes or adding important features from the roadmap etc. https://ubuntu.com/blog/tag/papercuts https://ubuntu.com/blog/tag/papercuts https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission https://wiki.ubuntu.com/One%20Hundred%20Papercuts/Mission Some companies have a "20% time (or X hours) on open source" policy, which is great for the sort of issues mentioned above. Some open source projects have a list of ways companies can support them with resources (like sponsorship, download mirrors etc), for example here is the one for Debian: https://www.debian.org/intro/help#organizations https://www.debian.org/intro/help#organizations It is a good idea to reword your employee contracts to mention the company policy on open source and give employees copyright over their contributions to open source projects. Some projects like Samba do not allow corporate copyright ownership. For other open source projects, having a diverse copyright holder base of individuals and a broad contributor community helps protect projects (at least those that are copyleft) from license and other changes brought on by company acquisitions, industry competition and other corporate influences. https://sfconservancy.org/contractpatch/ https://sfconservancy.org/contractpatch/ If you want more separation between your company software and open source software, an Open Source Program Office or just an internal "open source team" is a good idea, although it is always a good idea for lots of folks to have open source experience, so rotating other employees through the team for periods/percentages of time might be good too. https://blog.opensource.org/what-is-an-open-source-program-office-and-why-you-should-have-one/ https://blog.opensource.org/what-is-an-open-source-program-o... When setting up an internal "open source team", the FOSSjobs website and the other job aggregators linked from the FOSSjobs resources wiki might help you hire new open source folks. https://www.fossjobs.net/ https://www.fossjobs.net/ https://github.com/fossjobs/fossjobs/wiki/resources https://github.com/fossjobs/fossjobs/wiki/resources PS: if you need advice more specific to your situation, see my profile.