Notes from VM Brasseur's Open Sourcing Internal Projects talk OSCON 2018

gistfile1.txt

Open Sourcing an Internal Project

VM

Author of fossforge.com (book in beta)

Releasing software is just the start.  If you want to get stuff, throwing code over the wall  won't get you it.  Guides you find for "how companies OSS" are too generic, you need to figure out what's specific to your company.  

Slides: archive.org/details/oscon2018-internalproject

Most important part: Identify Company Goals
  why are you doing this?  this is the foundation
  it's OK to want to get something out of releasing it.  You'll spend a lot of time OSSing it.
  if the company can't agree on what benefits the company wants, you'll have problems
  you know what I like as much as free software?  solvent companies.
  you don't have to be an altruist.  
  goals are unlikely to be directly monetary, but there are other things you can get.

What you want to get out of it will help you determine:
  - what audiences to approach
  - what metrics to track
  - how to determine success
  - you won't know if you're failing otherwise

Whatever your reason is, the community must also benefit too.
  Not altruism, cooperation.
  Have to collaborate in good faith.

If you can't show ROI in your company, the OSS effort will be the first thing cut when budget time comes.  

Once you have a goal, next steps
  perform prerelease hygene.  
  remove the time-bombs
    - credentials in the code
      Maybe you committed your S3 login?
    - trademarks.  are there trademarked terms in your code/comments?
      maybe a dev cursed out google in their comments
      you don't want scrutiny by google lawyers
    - profanity or rudeness
      it's ok if it's your culture, but not when stuff is public

  review for license compliance
    - if your license is not OSI-approved, it's not OSS
    - all licenses have terms & conditions
    - most terms triggered on distribution, so you need to care when you
      OSS and distribute your project
    - make sure you are in compliance with the licenses for the libraries you
      code depends on
    - get your lawyers involve.  if you don't ahve an IP lawyer, retain one

  clearlydefined.io
    - child project of the OSI
    - single repo of copyright & licensing info for many popular OSS projects

  CLA/DCO
    - Most lawyers want a CLA.  Some will flex and require a DCO.
    - (definitions)
    - evaluate goals, make sure that a CLA makes sense for you
    - there's a lot of admin & maint associated with CLA
    - everyone had to sign.  who's going to store the signed docs?  who's going to secure the PII?
      who's going to make sure that all contribs are CLA signers?

  Contributors file?
    - you need to tell people up front how to contribute.  put the braces in the right places, use spaces instead of tabs
    - how to communicate
    - here's the CLA
    - here's style sheet
    - etc.
    - need to have this before you go live

  You must also have a CoC.  "that's table stakes"
  Most people don't care, but some people won't contribute.  Go go contributorcovenant.org, just use that.
  Learn how to enforce it.  That should be listed in your contrib file.

  - Issue templates: GH & GL both support
  - Styleguides? I guarantee you care.  You just don't have it written out.  Set it up up front.
  - CI/CD: how will that work?  You can just use travis, but someone needs to set it up and maintain it.
    but you cannot use the internal CI/CD anymore.

Choose a license
  - this should be the LAST thing you do.
  - not the first
  - you do need a license, if you don't have one, it's not legal to share.
  - the important part is all the other stuff, not the license, you just need one
  - license may be determined by your dependencies
  - I like GPLv3, but that's not good for all my clients
  - it's a spectrum, it's like gender, it's not just one or the other. there is no
    right or wrong there is no one true license.


When you apply a license, you need to annotate the files etc.
  each file may need a copyright statement.  If the file is separated, it needs to 
  still have a header with a license statement.
  yeah, it's a pain, but c'mon, just script it.  add it to your CICD or your linter

Respect the community.  Someone will show up. 
  - you can't maximize benefits if you don't
  - if your company could get there without other people, you wouldn't release
  - you can't gain benefits without a community, but you can't gain community without trust
  - first, work in the open
  - you must listen.  don't just dictate to them.
  - community needs to feel like stakeholder, not like a free labor force
    they will fork and walk
  - be patient, building community takes time.  it won't happen in 2 months or 6 months.