Skip to content

Design principles

probonopd edited this page Jul 3, 2019 · 2 revisions

Design principles

End user experience

  • End user experience above everything else
  • KISS. Keep it simple, stupid
  • "It just works" without people having to take additional steps, configure things, read docs (no one does), etc.
  • It needs to work on all still-supported target systems (distributions)
  • Macintosh System 1.0 and Mac OS X 10.0-10.4 are roughly the benchmark
  • Polish. Attention to details
  • No unnecessary clicks
  • No unnecessary screens
  • No unnecessary questions
  • No unnecessary technobabble
  • AppImages shall feel "native" and not "special"
  • One app = one file. This implies that the file manager is the primary tool to manage AppImages, just like every other file
  • AppImages must work offline and must not require something to be downloaded in addition to the AppImage itself

Application developer experience

  • If there is a trade-off between a burden for either the developer or the end user, it's the developer who should have the burden, so that the experience is super easy for the end user
  • Our tools for application developers should have a stable CLI so that if they set up AppImage generation once, it should ideally work forever without them having to make changes as our tools progress. If we make changes to the tooling "under the hood", application developers should not notice it
  • Our tools for application developers should "just work", i.e., do as much "automagic" as possible so that ideally one line of code produces a working AppImage that conforms to all relevant specs including AppImageUpdate

AppImage developer experience

  • Contributing to the AppImage should be easy and fun, especially for new and "drive-by" contributors
  • It should be easy to fork our work without hassle, hence no private infrastructure but everything must work in the "public cloud" that anyone can just click on "fork"
  • No complicated tools or languages that make things cumbersome and hard to understand should be used so that everyone can contribute easily. Wherever possible, "universally known" standard tools like bash, Markdown should be used
  • The core elements of AppImageKit (appimagetool, appimaged, libappimage, documentation) should be in one repository so that every change or pull request in one of those elements produces a new continuous build that can immediately be tested on a local machine

AppImage project governance

  • We are distribution-neutral and vendor-neutral
  • We are open source under a non-copyleft permissive license (MIT)
  • We are friendly toward closed source application vendors
Clone this wiki locally