There's a lot of backstory here, that I'm going to ignore. This is not a rant, or a personal attack, or a justification. I want to explain the way I see things and where I want to take them.

When I began using Arch, we had the philosophy that we were "as vanilla as possible". This means that we trusted the upstream developers. If an Arch user wanted featureX, they contact the upstream developers, asked for featureX. Whatever upstream's decision, yes or no, we went along with it. We did NOT add the feature to our package anyway.

When I began using Arch, we had the philosophy in mind to "Keep It Simple, Stupid". This means that if things were too complex, we did it another way, or didn't do it ourselves. Someone wanted custom hardware modules? They could build them themselves.

When I began this all, we kept things as simple as we could, and allowed (and actually encouraged) people to change things they wanted to. This was the core of Arch - if you don't like it, do it yourself. We told people "If you don't like how the maintainer did that, use ABS and rebuild it". We told people, "If you want a package for that, make it yourself". We had users that knew this, and worked in tandem with us. Some users provided custom repos, different PKGBUILDs, alternatives.

This has all changed. For the worse. And it shows in the mentality of our patching. One user requests a feature, we apply a patch - we don't worry about upstream. One user has a brand-spanking new sound card, kernel gets patched. One user doesn't like a configure flag in a package, it gets changed.

We can't continue like this. Arch wasn't made to sustain itself in this way. Arch was made to work in tandem with the users - users that can help themselves AND us. Arch was made to work with you, not for you.

The Arch Way is a document that has been around for some time. It defines the core Archlinux philosophy - what makes us tick.

Here is my take on that document. My version of what we provide the user.

In short, the Arch Way is about simplicity and giving control to the user. Keeping things simple, and agile.

Arch is lightweight and simple, like clay - able to be molded by the user as they choose.

Arch is not a distribution made for "user friendliness". It is a distribution designed to be a platform - a "base" for the user to do what they want. This means that we don't try to force a user's hand into our way of doing things, with our configuration tools, and our ideas. It should be about their ideas.

It is important who controls the system here: the user. Developers suggest things, and push in certain directions, but let the user do as they wish.

Arch is a base for anyone to make into whatever they see fit. Arch is a tool.

Use it well

Furthermore, the driving philosophy behind Arch is provided in this document. Here, again, is my take on this (really just reworded).

• Keep It Simple, Stupid: A simple design is usually the most elegant (See also Occam's Razor)

• 'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use, and technically crap.

• Relying on complex tools to manage and build your system is going to hurt the end users. Maintenance and upgrading should be an active process, not a passive one.

• "If you try to hide the complexity of the system, you'll end up with a more complex system". Layers of abstraction that serve to hide internals are never a good thing. Instead, the internals should be designed in a way such that they NEED no hiding.

• We can't help you. Yes this is a philosophical point. Every Arch user is expected to be able to help themselves - to be able to look up information, configuration files, bugs, etc. You're expected to be able to do a little research when you have a problem. Teach a man to fish, and all that.

• We are, above all, a community oriented distro. Contributions and effort from the end users should never be discouraged.

• Unlike other distros, Arch is not primarily concerned about the user. The user is important, sure, but most important are simplicity and elegance. The user is important as long as it does not interfere with these doctrines.

• "It is what you make it" -- Judd Vinet

With the advent of the "new leaf" for Arch, I figure it's time to explain, to those of you who don't know me that well, how I go about this development thing.

See, I have one defining principle that is covered pretty well in the Python Philosophy.

Now is better than never.

Really, this is a simplification of Pareto's principle - also known as the 80/20 rule.

See, I am a strong supporter that completing 80% of the work that is "easy" as soon as possible and in a functional manner, is far better than waiting for 100% completion.

To make this an analogy: If I were building a house and it's the only shelter I had, I would rush to at least get the roof up. That's just a small portion of the work, but it is functional - I could sleep under it and all that fun stuff.

When I try to explain this to people, I describe it like molding clay. If you are sculpting a 1:1 scale human being, out of clay, you don't start on just the ear, make it perfect, move to the cheek, make it perfect, etc. No. You take a lump and make it look kinda like a human, maybe add some small details, go over it with another pass, add some muscle definition, another pass to clean up some things and fix inaccuracies, and another pass for fine details.

This is how I attack these things.

You don't need a perfect fool-proof plan. It's impossible to make something fool-proof, because fools are so ingenious. Someone will always piss in your proverbial cereal. Accept it. Accept that 80% is just as good. Accept that the ear doesn't need to be perfectly defined right away.