A Tale of Two Developers: Finding Harmony Between Commercial Software Development and the Apache Way
summary
Company engineers build a Rainfall feature, post a patch to the mailing list, hit an upstream veto, and resolve it by reworking code, publishing the patch publicly and tracking feedback in JIRA so the change lands; merit comes from sustained high‑quality patches plus doing code reviews, not employer badges; documentation work earns commit rights too (10 docs patches vs 20 code patches cited); toxic comments drive contributors to competitors, so the project enforces community over code, expects everyone to wear your Apache hat, and practices no jerks allowed.
AI-written summary · about
chapters (10)
- 0:00Intro
- 9:09Value of Open Source
- 10:51Why the ASF
- 11:33Key Takeaways
- 12:53Act 2 Good Character
- 15:51Act 3 Committing
- 22:13Discussion Questions
- 23:56How to Become a Committer
- 27:48Public Forum Decisions
- 29:47Takeaways
related talks
41mA user's perspective on open source
35mDecoding 'Community Over Code'
01h 00mGrow and manage your open source project with a proven way - The Apache Way
49mCommunities Over Code: How to Build a Successful Project
15mOpen Source Protips from the Trenches
29mOpen Source Contribution - How does it even work?
38mHow To Be a Responsible Open Source Citizen
41mThe Open Source Effect