Re: [Gnu-arch-users] may I pick your brains?

[Brian May]

>>>>> "Paul" == Paul Cory <address@hidden> writes:

    Paul> So far, the suggestions have been from the folks really know their
    Paul> arch and version control stuff. However, the anecdote applies to
    Paul> convincing managers, who don't always understand what all the cool
    Paul> technical stuff means or, more importantly how it affects their
    Paul> goals. While I'm a revision control newbie, I do a lot of explaining
    Paul> technology benefits to less technically astute management types. I
    Paul> also something of the factors I and others in my organization use in
    Paul> making technology decisions.

Ok, I will bite ;-).

Disclaimer: I am not a manager.

    Paul> 1) How will arch make my people more productive? Why is it
    Paul> better than X (subversion, CVS, Bitkeeper and so on)? The
    Paul> technical details can be quoted to support this, but this is
    Paul> the most important consideration for the manager.

Arch will allow you to become more productive as it has a number of
important features that are lacking in competing products. Arch fully
supports moving directories and files, so major code reorganisation is
possible without losing file history. Arch supports distributed
repositories and disconnected operation, ensuring productivity is not
lost when a connection to a central server cannot be made.

[ I deliberately avoided mentioning branches here; that would mean
explaining to the manager: what is a branch? why do I need branches?
etc. Too much detail, IMHO. ]

    Paul> 2) Who's using arch for what? It really helps to be able to
    Paul> point a manager type to a successful project similar to what
    Paul> you're attempting to do, or better yet, is larger and more
    Paul> ambitious than what you're attempting. A track record is
    Paul> hard proof that the product works in the real
    Paul> world. Managers like that - it reassures them that this
    Paul> isn't a blind alley they're going down. For example,
    Paul> Apache+mod_perl is much easier to defend to my managers when
    Paul> I have places such as Salon.com to point to.

Arch is used to store Arch, meaning arch has a successful track record
for a product that works in the real world. This means you will not be
going down a blind alley by using Arch.

[ Seriously, somebody else can do this one... ]

    Paul> 3) Is our data safe?

Under arch, all data is safe and protected. Not only is it easy to
create backups/mirrors, you can do so without taking the archive
off-line. Even if data is corrupted, it is in a simple format making
repairs easy. Archives can be cryptographically signed, making it
difficult to make fraudulent changes without leaving evidence behind.

    Paul> 4) Arch is under continuous development and support options are
    Paul> available for it. Yes, I know the joy of Open Source is that you get
    Paul> the source code to work with. But my organization, like most, doesn't
    Paul> have the capability to maintain or extend arch, so it's vital to know
    Paul> that bugs are being fixed, features added and so on, on a regular
    Paul> basis. It's also vital for us to have a place to go for support. Paid
    Paul> is nice, but not necessary - what's important is that support is easy
    Paul> to get to and quick to respond, even if it's e-mail.

Arch is actively maintained and supported by the international
community. I have found support to be prompt on the mailing list.

[ this type of organisation may not want to subscribe to this busy
  mailing list though ]

    Paul> 5) What platforms does it run on? If it doesn't run on the operating
    Paul> systems my organization uses, it's not an option.

Arch runs on any Unix platform including Linux. As Linux is used
almost exclusively throughout the planet and galaxy, you will almost
certainly be able to use Arch without question on anything from your
desktop computer to your fridge, microwave oven or hairbrush.

errr... Obviously there are some dodgy answers here; I agree with Paul
though, we have to write this in the perspective of the manager and
try not to overwhelm with excessive detail or jargon.
-- 
Brian May <address@hidden>