Paying people to work on open source is good

Paying developers to work on open source software is widely seen as necessary for sustainability, but sparks disagreement over who should fund it and under what conditions. Commenters weigh corporate sponsorship, grants, government programs, and “freemium” or support-based business models, noting tradeoffs between financial viability, project direction, and community control. A major fault line runs through the definition of “open source” itself, with some insisting on OSI-approved licenses and others embracing more restrictive, source-available licenses as pragmatic adaptations to the cloud era and corporate exploitation.

Overall sentiment on paying OSS maintainers

  • Broad agreement that paying people to work on open source is beneficial.
  • Multiple commenters donate personally (often a fixed % of income) and/or organize structured giving through nonprofits based on tools’ importance.
  • Some stress celebrating any sustainable path for maintainers (employment, grants, support contracts, etc.), rather than purity about the source of funds.

Concerns about “always good” and business models

  • Several argue payment is not always good: corporate sponsors can steer projects in user‑hostile directions or prop up exploitative business models.
  • Others counter that “perfect must not block good”: until public funding exists at scale, corporate money is often the only realistic option and forks remain a safety valve.
  • Worry that some “wins” (e.g., corporate-funded, user‑hostile OSS) are actually net negatives, especially when they entrench de facto monopolies.

Funding mechanisms discussed

  • Grants: helpful but unstable, usually tied to specific features; not sufficient alone.
  • Services, consulting, hosting, support, and paid “enterprise” features are cited as successfully funding fully free software in some ecosystems.
  • Threshold pledge / “Kickstarter for features” models are referenced (e.g., Blender’s GPL release) but seen as limited by free‑rider incentives.
  • Proposals for “quasi‑open‑source” or source‑available licenses plus a foundation that collects mandatory business contributions spark debate.

Debate over the definition of “open source”

  • One of the most heated threads: some insist “open source” must mean OSI‑compliant licenses with no use restrictions; everything else is “source available.”
  • Others advocate a broader, more pragmatic umbrella that includes licenses like BSL, Polyform, and other post‑cloud variants, arguing the original “open source” push was itself business‑oriented.
  • Strong fear of “openwashing”: diluting the term to cover open‑core, bait‑and‑switch relicensing, and restrictive source-available schemes.
  • Some say they’d rather see projects die than relax the OSI‑style definition.

Economics and who should pay

  • OSS is described as a public good with classic free‑rider problems; libraries as complements that structurally favor consolidation.
  • Many argue most users care primarily about “free as in price,” not freedoms, which skews incentives.
  • Repeated sentiment that large companies, not individual developers, should bear most funding responsibility; suggestions include corporate OSS budgets and volunteer‑time PTO.

Government and public-sector role

  • EU models like NLNet and the German Sovereign Tech Fund are praised; some want a similar US mechanism.
  • Others are skeptical of direct government involvement due to bureaucracy and waste, favoring independent foundations that channel public money.

Impact of paid contributors

  • Examples from some language ecosystems show that a small number of full‑time funded contributors can dramatically improve documentation, UX, and cohesion.
  • A minority warns money can distort community dynamics and that paid teams may later abandon projects, leaving users with unexpected maintenance burdens.