To write a computer program, you need to provide a bunch of other guff that has little to do with the program you are writing.

  * Licence
  * README
  * Build system (ideally an 'hermetic' build system that insulates your build configuration from the surrounding environment)
  * Test runner
  * Documentation!
    * Something to build docs
    * Something to publish docs
    * API docs
    * Long-form documentation (e.g. how to, design)
    * Change log
  * Release process
  * Code review system
  * Version control
  * Web site
  * Discussion forum
    * IRC?
    * Mailing list?
  * Version numbering
  * Coding standards
  * Linter to support coding standards
  * Continuous integration (ideally something that prevents merging patches that break tests)

----
Additions from others:

  * Somewhere to file bugs (@sil)
  * Code of Conduct (@popey)
  * Installation instructions (@sil)
  * OS-specific packaging
  * A name (@puzzlement, Jani Monoses)
    * Make sure people can search for it! (@puzzlement, @froztbyte)
  * Forum for announcements (Jani Monoses)
    * Blog?
    * Twitter?
  * Landing bot (@bigjools)
    * Something that acts on code review approval by merging, might not be necessary depending on overall setup. (e.g. Github doesn't have "Approve" it just has "Merge").
  * A dependency list (Chad MILLER)
    * If you have a hermetic build process, you don't need another one of these
  * Instructions / script for running from source (@froztbyte)
    * Remember, plenty of potential users/contributors will be unfamiliar with your language's toolchain! @froztbyte [good call - jml]
    * "`./makethisrun --devmode` should be able to give me all I need to tweak things. debug logs, warnings of missing packages/tools," @froztbyte

----
Serious business!

Things that I personally think are optional, but are good ideas, especially if you've got a bit of momentum or you're hiring lawyers.

  * Logo / branding
  * Contributor agreement (@popey) [jml _still_ doesn't think this is necessary or desirable]
  * Release schedule (Bjoern Michaelsen)
  * Roadmap (Jani Monoses)
  * Documentation style guide