Publishing what you built.
WHY BUSINESSES DO IT
Attracting contributors and users Establishing a standard Recruitment and reputation Reducing the cost of maintaining something alone Commercial models built around it
WHAT TO ESTABLISH FIRST
Why you are doing it.
WHY
The reason determines the licence, the model and the effort required.
WHAT TO ASSESS
Whether the code is something others would use Whether you can sustain it Whether releasing it damages your commercial position
WHAT TO NEVER RELEASE
Anything that is your competitive advantage Anything containing confidential material Anything you do not own entirely
WHY OWNERSHIP
Code containing third-party material you cannot relicense cannot be released.
WHAT TO AUDIT BEFORE RELEASE
Every component included, and its licence Credentials, keys and configuration Internal information in comments and history Customer data in tests Third-party code
WHY THE HISTORY
Version control history persists and it contains what was removed.
WHAT TO DO
Review the full history, or publish without it.
WHAT TO DECIDE
The licence.
WHAT DETERMINES IT
Whether you want it used in proprietary software Whether you want modifications contributed back Whether you intend a commercial model
WHAT TO ESTABLISH
What you actually want to happen.
WHAT TO PREPARE BEFORE RELEASING
Documentation sufficient to use it Clear installation instructions A licence file Contribution guidelines A route for reporting issues and vulnerabilities
WHY
Released code without documentation is ignored.
WHAT TO ESTABLISH
Who maintains it.
WHY
Abandoned released projects damage reputation.
