..     Licensed to the Apache Software Foundation (ASF) under one
       or more contributor license agreements.  See the NOTICE file
       distributed with this work for additional information
       regarding copyright ownership.  The ASF licenses this file
       to you under the Apache License, Version 2.0 (the
       "License"); you may not use this file except in compliance
       with the License.  You may obtain a copy of the License at

         http://www.apache.org/licenses/LICENSE-2.0

       Unless required by applicable law or agreed to in writing,
       software distributed under the License is distributed on an
       "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
       KIND, either express or implied.  See the License for the
       specific language governing permissions and limitations
       under the License.

Why not improve existing tools like Trac, Redmine or Bugzilla?
---------------------------------------------------------------------

One word.  Scalability.

Ok, two words.  Scalability and Performance

Ok, three words:  Scalability, Performance, and Flexibility

Seriously though, we didn't think that any of the existing systems have
actually hit the right usability, scalability, or flexibility targets that
we needed to hit, and we knew that it would be a **lot** of work to get
any of them to do what we needed.

But we knew e-mail integration was going to be a big deal to our forge,
so we did take a long look at Roundup, which is a very well designed
system build from the ground up around the idea of e-mail integration.

If you were so inspired by Roundup, why not just use it?
---------------------------------------------------------------------

We liked the flexible schema system provided by Roundup's HyperTable layer,
but thought that native MongoDB bindings were both cleaner, faster, and
ultimately more powerful.

Sure we sacrifice the flexibility of Roundup's
backend, but our main goal is to make usable, high performance system,
not to maximize the number of backend storages systems supported.

Why create all the apps as plugins?
---------------------------------------------------------------------

We know that some projects are going to want more locked down
access controls in their bug trackers, or more workflow based
processes.  These things are inevitable, and we really do want
to support them, but at the same time they are going to conflict
with the way many other projects want to work.

Building a plugin (tool in Allura terms) system, and standard
integration points makes it possible to serve everybody in one
way or another.

Why not just allow web-based extensions?
---------------------------------------------------------------------

We talked about this quite a bit, and decided that we could write local
native tools more quickly and easily, and that we could build a
local app tool that proxied out to an external webapp, and that
we could provide a lot more flexibility by allowing custom
external webapp proxies -- which brought us right back to local
tools.