Ideas about potential goals for Borg

Borg is a fork of Attic and it was done to allow some different approaches to development, goals and policy (for details about how and why the fork happened, see jborg/attic#217 and the attic mailing list):

Openness

• Borg is intended to be an effort by "The Borg Collective"
  (see AUTHORS) and you can be assimilated into it, if you like.
• Welcome feature requests, discuss their general usefulness.
• Accept pull requests of good quality and coding style,
  give feedback on PRs that can't be accepted "as is".
• Openly discuss about stuff, don't work in the dark.

As simple as possible, but not simpler

• Nobody likes tools that are too complicated, ...
• ... but nobody likes everything to be fixed and inflexible either.
• Do the usually right thing by default, but offer other options.
• Accept the fact that the usually right defaults might be totally unfit
  for some users / use cases.

Compatibility - boon and bane of backup software

• Don't break it accidentally / without good reason / without warning.
• Break it if above does not apply. needs more thoughts/discussion
• As the fork is "new software" from the perspective of a Borg user or
  a Borg packaging distribution, there is no past we need to stay compatible
  with - we have the chance to break compatibility and change everything
  that we think needs changing.
• Over time, we'll have more users and incompatible changes get harder.
• Avoid getting into the "compatible forever" trap - we should maybe not
  assure compatibility of development versions nor spanning major releases.
• When used for long-term archiving, special considerations and care are required.
  E.g. a development snapshot of Borg might be not the right thing for this.
  Also, Borg exists to be able to change things. So if you don't like or can't
  live with a changing software, don't use it.