Decision

<aside> ✅ Option: Why?

</aside>

Context

• Discussed a bit in ‣
• Discussed a bit in https://github.com/mui/base-ui/pull/3709#issuecomment-3733708193

Problems

1. Outcome-based reward. We could create bounties on issues, but how do we know how much to allocate? How do we correlate back to value for users? It’s hard.

   There are sub-problems that have clearer measurable benefits; for them, we could have a more automated reward system, which scales. This would be similar to security reports bounties ‣. Introducing:

   • For bundle size win:
     • Problems:
       • https://github.com/mui/base-ui/issues/3688
     • How do we measure it? Our bundle size tracker infrastructure.
     • Proposal: A. “The great shave off”
   • For Performance win:
     • 1ms saved = $1.
     • How do we measure it?
     • Proposal:

2. Hiring. Once you see someone doing great work, you can try to hire them.

   For example, how Sebastian Silbermann joined us, before he joined the React core team and Vercel.

Options

A. “The great shave off”

How the program would work:

• Which scope?

  • Any repository under https://github.com/mui is eligible for the program as long as the bundle size is accurately tracked.

    (The reward per byte saved could vary per repository based on the priorities.)

  • Any open-source contributor can claim a reward; we only try to keep it balanced, leave space for multiple contributors to take issues, and not only one person.

    (MUIers are not eligible, as bundle size management is part of their core responsibilities; this program is meant to allow us to delegate work to the community, to get leverage.)

• Conditions for the gzipped bytes saved to be valid?

  • The change must not involve noticeable maintenance overhead (e.g., logic that is hard for humans or AI to reason about). If there are, the win could be considered null and not even merged.

  • Public submodules of an npm package can’t have their size increase by more than 10% of the main package's size reduction.

    Why: Having small entry points is more important than minimizing the total npm package size. People will never use all the modules of the npm package, so it’s not that relevant; it also means that they can't truly compare the total npm package size between us and some other option. However, they can compare the size of the first few ES modules that they will adopt between us and different libraries.

  • The size used for the $ reward is the gzipped size reduction of the first npm package that is fully impacted in the ES module dependency chain.

    Examples:

    • @base-ui/react is the first public package, the only one. So the win is -24B.

      

      https://github.com/mui/base-ui/pull/3805#issuecomment-3776988451

    • x-charts-premium depends on x-charts-pro, which depends on x-charts, so the win is -63B.

      

      https://github.com/mui/mui-x/pull/21390#issuecomment-3926299905

• What’s the $ reward?

  • The $ reward function is **gzipped bytes-**based:

    $x = \text{byte minified gzipped saved}$

    $\text{if x ≤ 400} : \text{\$} = x * 1.5$

    $\text{if x > 400} : \text{\$} = 400 * 1.5 +\left(x\ -\ 400\right)^{\frac{1}{1.16}}\ \cdot\ 1.5$ = (400 * 1.5 + (x - 400) ^(1/1.16) * 1.5)

    https://www.desmos.com/calculator/j763akgpmj

    • So:
    • 24 bytes saved = $36 - https://github.com/mui/base-ui/pull/3805
    • 0.4 kB bytes saved = $600
    • 4 kB bytes saved = $2,345

    vs. https://bundlejs.com/?q=https%3A%2F%2Fesm.sh%2F%40base-ui%2Freact size: 114 kB.

  • Why this formula?

• How can I get paid?

  • Submit an expense at https://opencollective.com/mui-org. Group them for the month if you have multiple.
  • Have a link to the @mui-bot comment with the Bundle size report saved value.
  • For the expense, add one row for each PR that is eligible for this program.
  • Use this as the row description: “The great shave off + bytes saved + Link to the PR”.

• For the operations team handling expense claims.

  • Verify for each expense row that:

    • The byte value is correct.

    • The $ value is correct.

    • The GitHub label the great shave off wasn't already applied

      (This avoids double-counting for finance and helps measure the traction of the program for product engineering.)

  • (as usual, verify that the total of the invoice is correct)

  • Add the tag: the great shave off, on the transfer in Open Collective.

  • Add the GitHub label the great shave off for each PR approved.

B.

Proposal

Option:

Why?