I'm in touch with a company that is trying to figure out how to best help specific Open Source projects that they depend on (i.e. that are part of their SBOM). I'll do something unusual for me today, and do a public braindumb on the topic, and adjust these notes over time. Let's dive right in:

Why help Open Source in the first place?

Benefits of helping the Open Source projects that you depend on include that:

• your software dependency is more likely to stay in good enough shape to fix vulnerabilities and release security fixes with little delay, and that increases your own products security
• you avoid a "riding a dead horse" situation without knowing
• you get organic marketing (brand visibility, value signaling, attention from potential hires, ..)
• you get a feel of being part of the solution
• you build relationships for the future

What state does the project need to be in to be considered healthy?

Project health has many aspects, some less obvious, in particular to non-developers. All aspects of project help offer unique opportunities to be helpful.

To be a healthy dependency, you want the following future state for the project (in no particular order):

• maintainable and secure code,
• maintainable build system,
• tests and good test coverage (to avoid bugs and regressions),
• secure CI pipeline running the tests (to avoid regression),
• static analysis in CI (to reduce introduction of bugs),
• runtime analysis (to reduce introduction of bugs) e.g. use of AddressSanitizer and UndefinedBehaviorSanitizer with C/C++ projects,
• code auto-formatting and checks for formatting violations in CI (for readability, morale, efficiency of review),
• support for recent toolchains (e.g. recent compilers, for agility and morale),
• (no support for ancient toolchains (for agility and morale),)
• an all-warnings-addressed situation (e.g. using -Werror -Wno-error=... in CI (but not in packaging) for C/C++ code) or actively working towards reducing the list of explicit exclusions for all static analysis tools in use,
• collaborative attitude among project contributors,
• low number of stuck issues (for morale and efficiency),
• low number of stuck pull requests (for morale and efficiency),
• timely, thorough, co-operative code review for pull requests (for morale and progress),
• timely and co-operative responses, analysis, discussion in issues (for morale and progress),
• integrated use of fuzzing (to detect unknown vulnerabilities) with good fuzzing code coverage (upstream and/or in OSS-Fuzz).

How to fund help in general?

There are multiple options:

• a) pay existing hands upstream (through funding or employment) that are open to direct funding
• b) bring new hands that you already pay for (e.g. through ongoing employment)
• c) bring new hands that you will pay for
• d) combinations of (a), (b) and/or (c)
• e) pay a third party to organize (d) for you well

Every project is unique in the needs: some maintainers are happy to spend more of their own time for compensation, others are already at their limit of spending time, need self-organizing additional hands, have no use for payment at all, and so on. Finding the approach that works for a specific project through analysis and discussion is key.

What are the challenges in funding a project?

1. Paying contributors can get them into situations of conflict of interests.
2. Paying contributors can create an atmosphere of envy and injustice.
3. Paying contributors can become tricky legally when they work on the project during both work hours and spare time, e.g. with regard to legal maximum de-facto work hours per day.
4. Paying existing contributors can affect their motivation to work on the project for better or worse.
5. Paying existing contributors on project A can make them neglect other important duties, e.g. work on project B.
6. Producing more (or too many) non-trivial pull requests takes away time from existing contributors (and can hence hurt more than help).
7. Some contributors like to avoid voice/video calls and some like to avoid text ping-pong, i.e. individual needs need individual approaches.

What can be done about these challenges?

Some ideas about how to tackle these challenges:

• For (1) communicate (and mean) that you understand and expect that their conscience, ethical behavior and the community interests of the project are at least as important as your business interest.
• For (2) consider approaching the whole project on the topic of funded contributions before starting to fund.
• For (3) discuss the issue with funded contributors upfront.
• For (4) discuss the topic with funded contributors upfront, to get a sense for the kind of affect you would have.
• For (5) discuss their situation in life and other duties with them before funding.
• For (6) discuss with existing contributors:
  • how to maximize pull requests for reviewability to their eyes,
  • how much volume or pace of contribution they can sustainably handle at the moment,
  • whether voice/video calls or text ping-pong fits there individual needs better, and
  • which issues (or types of issues) to start helping with and which issues to not touch at the moment.
• For (7) discuss with existing contributors.

Take home points

• It can be done.
• Every project has different needs.
• There are plenty of things that projects need help with.
• Doing it wrong can hurt a project and make matters worse.
• You have a unique profile what kind of help fits you best.
• Tip: You can bookmark this page to find your way back here easily later.

Did any of that hit a nerve with you or made no sense at all?
Let me know and have a nice day!