Abstract

From navigating different incentive structures to fostering healthy collaboration, this practical session delivers hard-earned wisdom from 25+ years of open source experience. Whether you’re a newcomer curious about contributing or a seasoned maintainer, “Open Source Survival Guide” offers concrete rules that help technical professionals, community leaders, and companies work effectively in open source environments. Learn how to build trust, share knowledge, handle contributions, and avoid the pitfalls that can damage projects and careers.

Description

Key Terms and Organizations

  • Upstream: The open source project
  • Downstream: The product based on open source project
  • Upstream vs Downstream
  • Open Source Initiative (OSI): Governs open source definition and licenses
  • Linux Foundation: Oversees many open source foundations (501(c)(6) non-profit)
  • Apache Software Foundation: Oversees many projects (501(c)(3) charitable organization)

What is Open Source

  • Definition: Software released under an OSI-approved license
  • Licenses comply with the Open Source Definition (OSD)
  • Different licenses grant different freedoms
  • Open source is a software development method, not a business model

Commercializing Open Source

  • Hosting and Support
  • Training, Certification, and Consulting
  • Sponsorships, donations
  • Dual licensing: free for personal use; paid for commercial use
  • Open Core (COSS): basic features open, value-add features paid
    • Controversial but has some success stories (MongoDB, GitLab, Elastic)

Free Software and Copyleft

  • Linux kernel uses GNU GPL version 2 from Free Software Foundation (FSF)
  • Copyleft licenses stipulate:
    • Works must be released with the original license
    • Works may be used, modified, and distributed freely
    • Derivative works are bound by the same conditions

Common Problems

  • Businesses not understanding open source
  • Open source communities not understanding businesses
  • Different incentives at work
    • Community, collaboration, and code are at the heart of open source
    • Revenue, efficiency, and customers are at the heart of businesses
    • Both are important for either to succeed

Rule #1: Don’t take yourself too seriously

  • Don’t take feedback personally (cannot stress this enough)
  • Stay grounded and balanced
  • Customer obsession ≠ Obsessive-compulsive

Rule #2: Be humble, open, and honest

  • Learn from others in the community
  • Leave assumptions at the door
  • Be friendly always
  • Welcome newcomers; encourage participation
  • Ask questions in public channels
  • Be transparent about your objectives
  • Share your knowledge with others

Rule #3: Everyone has an agenda

  • That’s usually OK (until it isn’t)
  • Coopetition exists
  • Look for opportunities to collaborate on shared goals
  • Review objectively and subjectively
  • Don’t disguise goals or agendas
  • You represent your organization and yourself

Rule #4: Make your own karma

  • Trust is earned over a long time; lost in a moment
  • Treat people with respect
  • Have empathy when interacting with others
  • “Carry the water, fetch the wood”

Rule #5: Meet community where they are, not where you want them to be

  • Learn tooling; ask for help
  • Contributors are globally distributed
  • Participate in planning, meetings, work sessions
  • Your first contributions will be very small
  • Don’t make uninformed assumptions
  • Follow available guides

Rule #6: Contribution comes in many forms

  • Never underestimate the power of docs
  • Release management is a great way to learn about project tooling
  • Never disregard or dismiss non-code contributions
  • Understand the product management used by the project
  • Projects often need help improving quality and documentation

Rule #7: Code reviews are a conversation

  • Be curious
  • Ask questions; never make assumptions
  • Nit-picking No Nos
  • Good code reviews takes time
  • Set aside periods of uninterrupted time to conduct code reviews

Rule #8: Explain your work clearly

  • Connect contributions to business goals
  • Contribution is an “AND”, not an “OR”
  • Be clear about time investment
  • Set up time blocks for contributing
  • Don’t expect contributions to occur in employee free time

Rule #9: Share knowledge regularly

  • Knowledge sharing is a key component of collaboration upstream
  • Share the why not just the how
  • Encourage distribution of useful information in your teams

Rule #10: No separate open source teams

  • Leads to an “us vs. them” mentality
  • All team members should be able to participate in open source projects aligned to company goals
  • Contributing ensures community and corporate health

Rule #11: Choose carefully

  • Choose the projects you depend on carefully
  • Some projects don’t work as open source
  • Weigh whether or not to release as open source
  • Don’t be afraid to say “no” (respectfully)