[arch-dev-public] Goals / Mission Statement

[Aaron Griffin]

On 5/29/07, Aaron Griffin <aaronmgriffin at gmail.com> wrote:
> Hey all,
> This has been brought up a few times by Andy, but it seems it's fallen
> on deaf ears recently.  I want to make sure we get this done this
> time.
>
> One of our recent "growing pains" we've had is that there is a certain
> sense of direction that is unclear.  We don't have a clear set of
> "goals" defined.
>
> So lets do that now.  Our dev wiki (for the benefit of the subscribed
> users) contains some ideas which are rather raw.  I will strip the
> names to make things anonymous.
>
> Below you will find the points listed in our dev wiki.  What I want to
> do, right now, is flesh this out.  We need to define ourselves a clear
> set of goals.  It's important to note that a goal is not "make sure
> packages go to testing" - that's an implementation detail.  A goal is
> something more ethereal, such as "provide stable, up-to-date
> software".
>
> I would like all of you to read through these (feel free to add your
> own) and try and list 3-5 of these that you feel are important.  On
> Thursday, I'd like to compile a list of the responses, and we can go
> through and cherrypick our goals from this subset from everyone - yes
> this includes those of you without write access to this list.  Email
> me directly, if you want to remain anonymous.
>
> Please look these over, and reply with anything you feel is important.
>
> Thanks,
> Aaron
>
> ----------------- Dev Wiki Entries -----------------
>
> * Provide the latest software as is practical, while aiming to achieve
> a reasonable level of stability
>
> * Not be dependent on any graphical interface for any system function
>
> * Remain a lightweight, general purpose distribution that is simple in
> it's implementation
>
> * Continue to be a strongly community oriented distribution
>
> * Provide a good set of reliable and modern Linux technologies for
> desktop, server and portable PCs
>
> * Be equally suitable for home, educational, small business and corporate use
>
> * Provide a solid base for creating custom Arch (ISOs and repos)
> variants for users specific purposes
>
> * Remain a "install once, run forever" distribution
>
> * Provide good i18n and l10n support
>
> * Simple design. Reasoning: "Debugging is twice as hard as writing the
> code in the first place. Therefore, if you write the code as cleverly
> as possible, you are, by definition, not smart enough to debug it." –
> Brian W. Kernighan
>
> * Vanilla. As few patches as is reasonable to make things play
> together in the ways necessary, and then primarily as stopgap
> solutions until things get fixed upstream. This creates predictability
> and allows smart people with general GNU/Linux knowledge to pick up
> Arch instantly. It also keeps us from maintaining more and more custom
> patches over time.
>
> * Easy packaging with pacman. The SINGLE thing that will probably keep
> me from ever leaving Arch is how simple it is to create packages with
> Pacman. The thought of ever having to write another RPM spec file or
> something else as obtuse or complicated or ill-conceived as that makes
> me want to toss my lunch. When I find new software on the Web to help
> me do my work, I can have it packaged and integrated into my bag of
> tricks usually in less than an hour. As a result of this simplicity,
> we have a Community who understands what's going on and can be
> productively helpful and supportive of each other.
>
> * Binary distribution. Unlike Gentoo, we can download and install
> Firefox on a reasonably fast machine with a reasonably fast link in
> less than a minute. Also, we test and certify binaries, so quirks of
> people's machines don't bugger up their compile processes. The result
> is that after a pacman -Syu, on any machine, most things just work.
>
> * This might not be exactly where or what we are, but someone once
> called Arch a "meta distribution". That is, it gives you tools and a
> very nice base with which you can do whatever you want. I think this
> also coincides with 2 of the "goals" I would like to see - that is,
> (a) like Andy said, we provide a very nice base system and not much
> more, and (b) "Slackware with pacman" - we get likened to Slackware
> enough, and I think the simplicity that slackware strives for is ideal
> for us as well.
>
> * I say focus more on the core packages.. the underlying fundamentals.
> Push the addons higher into the stack. I liken Arch to one of the
> BSD's, oddly enough. The BSD team focuses on handling the core. They
> deal with things that come about when the system goes from poweroff to
> running a base network os. Then ports managers handle the packages
> that lay on top of this core system.
> Just a thought.
>

I will get the ball rolling with my current thoughts on this.  My
ideal sets of goals for Archlinux are as follows:

* Provide the latest-and-greatest versions of software without
sacrificing stability
Please note I am NOT suggesting we "lag behind" or move away from the
"bleeding edge" type of software that we've been going for.  What I am
suggesting is that IF stability is in question, there is no reason to
release a new version while breaking things.  Stability may be a poor
word here.  Rather, I would like to phrase this as follows:
"Provide the latest-and-greatest versions of software with a
/consistent end user experience/".  The point here is that, some apps
are a little broken in general. There is no reason for us to go out of
our way to fix what the original developers feel is acceptable, but at
the same time, if programs get *worse* with newer releases, we have an
obligation to those using archlinux packages to "shield" them, if you
will, from crappy applications.  If we have to skip a point release so
that the app isn't entirely broken, then so what?


* Maintain the mantra of simplicity, in all things, including packages
and utilities.
By this, I mean that we need to stay "light weight".  Like the point
above about a "meta distribution".  If we focus solely on creating a
tight "core" with high quality, we allow others, more interested in
things, to maintain the outer layers of the onion.  A perfect example
is AEGIS.  The software that makes up AEGIS is important to a handful
of people, but not to everyone.  It is our job to make sure that the
AEGIS people (person?) do not need to worry about the next coreutils
release, or glibc.  It is their duty to watch over their software and
only theirs.

* Continue to be a strongly community oriented distribution
This is VERY important to me and relates to the previous point.  We
*are* a community distribution, like it or not.  Generally, there is
nothing that says that me, as a "developer" is more skilled than
another member of the community.  The difference is generally timing,
and effort and things like that.  But skill comes from everywhere, and
people have different goals for themselves.  We need to allow people
to follow *their* goals, which may be different from ours, but which
will, in the end, help us as a whole.

There's my set of goals for arch, the way I see us going forward.  To
reiterate, I see us:
* Providing the latest software within the confines of a consistent
user experience
* Maintaining simplicity in all things, including packages and utilities
* Backing the community, and letting users flourish around us.

As an analogy for the whole thing:
Arch is the top soil that one would plant his own garden in