Toolbox deployed

Mozilla has a lot of software tools for a wide class of problems we
typically encounter.  We're self-motivated people: when we encounter a
problem, sometimes we look or ask around to see if anyone else has did
anything similar, but if something doesn't turn up (quickly) we'll
write it ourselves.

This is pretty much how (the functional parts of) the Open Source
world works.  It goes hand in hand with the bazaar model:
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar . The
strength of the bazaar model is robustness: the process cannot be
stopped by any particular point of failure.  You get a robust
ecosystem of software that evolves in a manner parallel to biological
life.

The weakness of the bazaar approach, especially when considered as
part of an economic system, is that effort is duplicated.  The Open
Source revolution has made the greatest gains in proliferation: number
of languages, number of software projects, and ability to easily fork
existing code using distributed version control. But, just as the
federated web is harder to achieve than information silos, harvesting
and consolidating the vast richness of software is harder than its
proliferation and not merely for technical reasons.

Proliferation was largely a technological problem.  This is best
illustrated by DVCS. Consider the contrast between forking and
merging. With centralized version control, both forking and merging
are hard. With DVCS, forking is now trivial.  But despite the fact
that better tools have been introduced (which actually largely don't
have anything to do per se with DVCS), merging is a human problem.
Regardless of the amount of cleverness and hours required, technical
problems are solvable and will be solved.  Human problems can't be
solved simply by throwing resources at them.

Information curation will be the problem of this dawning decade.
Using the internet as the predominent informatic presence in peoples'
lives, the question has gone from "can this be done?" to "how do I
figure out how to do this?" (shadowed only by the overarching
question, "why am I doing this?"). Programming has lost its position to
UI/UX design.

Toolbox exists as a prototype to aid in unmixing the software tool
soup. It carries two related purposes:

1. To give people a place to put and find software tools of a wide
variety of types, purpose, and sources. To this end, a tool should
have a name, a description, a URL, and appropriate metadata. Mozilla
tools live in any number of places: in user repos, in shared repos, as
web apps, on github, or at any number of off-site hosts.  Often, for
reasons of convenience and legacy, a useful tool exists packaged [*]
as part of another tool or other piece of software.  In this sense,
toolbox is a software index, similar to PyPI or softpedia.

2. To give people a tool to curate the existing Mozilla tools towards
the end of consolidating similarly purposed code towards discrete
high-quality pieces of software. Often, as explained above, code is
duplicated. This is done because either an appropriate existing tool
could not be found (in an expedient manner) or existing tools were not
appropriate to the task at hand. Toolbox, as a software index, should
mostly solve the former case given proper participation.
If an existing tool is found to be unsuitable for the task at hand,
this can be for a few reasons:

- no such software exists to solve the problem. In this minority case,
  there is nothing to do but to write the software or reconsider what
  you're actually trying to do

- there is software that could be built on, but it is not an expedient
  solution to the problem.  This again can be for several reasons:

  * the modification to the upstream project is easily doable and
    expedient, but a lengthy review/approval process hampers is
    practicability to a solution within the time frame desired. This
    is essentially a problem in the area of deployment/packaging
    since, in the open source model, the upstream code is freely
    available, but concerns external to the code itself
    (i.e. distributability) require more than just the code
    modifications for continuation of an operable software process [**].
    In this case, an appropriate methodology is as follows:

    A. The issue is ticketed with the upstream project with the
    appropriate patch.

    B. A vendor branch is created of the upstream project with the fix
    applied.

    C. Relevent packaging/deploy systems are updated to point to the
    vendor branch instead of the upstream project.

    D. Changes to the upstream project are propagated (either manually
    or automatically) to the vendor branch.

    E. The change is accepted upstream.  If there are no other
    discrepencies between the vendor branch and the origin, the vendor
    branch is deleted and all references point to the origin. If there
    are discrepencies, the particular upstreamed change is removed
    from the vendor branch and fetched from upstream.

    While none of this is hard, it requires time, management
    (i.e. attention), and adequate tools.

  * the modification won't be accepted upstream.  This is similar to
    the above case, except the vendor branch will never (conceivably)
    go away.  It is usually not possible to distinguish the case up
    front or in any predictable time-frame.  It may also be
    conceivable to permanantly fork the project; that is, the vendor
    branch becomes a first-class resource (a project of its own right)
    versus a temporary necessity that should not (normally) be
    consumed downstream.

  * The modification to the code is hard in terms of required time to
    invest, required maintenance, and/or required attention to
    complexity. In general, the required work and maintenance will be
    unknown whereas the time to measure from nothing to a working
    solution may be more estimable.

- there are one or more softwares that nearly do what you desire, but
  not quite.  This is often due to a misclarity of intent of the
  software formulators, or software that may have originally had a
  clear intent but that has been adopted to fulfill more nebulous
  purposes. 

The above presents a best-practices scenario.  In order for open
source, as a global village, to sustain and flourish, the strengths of
open source -- the unconstrained flow of information, the championship
of the individual, cooperative advantage, and community ethics -- must
be utilized and best practices must be achieved as the flowerbed is
shared with corporate interests to which the open-source ecosystem,
while competition for market share mandating utilization via its
(often) excellent code base, the proliferation of potentially
non-moneyed (and non money-oriented) alternatives represents a direct
threat to the power structure[***].

More directly, effort must be made towards coherency and cohesiveness
of open source.  How does one bring order to the bazaar?[****] One
must begin with an understanding of how the bazaar works.  Open source
programmers are, by inspection, largely good citizens (after a
fashion).  They allow consumption and distribution of their work,
their source code, without exploit it for a capital
advantage[*****]. If the process of organizing is fitted organically
into their existing workflow, open source programmers will
organize. If the practical advantage to themselves and to the system
as a whole of organizing is perceived, a coder will go to the 
(non-over-burdening) required effort in order to make this so. When
first exposed to tools such as issue trackers, VCS, automated testing
(e.g.), programmers often first resist adoption of these technologies
until a case clearly manifests that the tool in question does (or more
often, would have) saved considerable time, effort, and/or
status. Then the developer uses the tool and will consider anyone who,
as s/he previously did, does not naive. This pointing of arrows is an
example of how the bazaar works: individuals are agents and operators of
information, but the transfer of information, which is in what makes
information valuable, is a transpersonal process.  You do not bring
order to the bazaar; you plant the seeds and nurture towards a
bountiful harvest.

------

[*] using the term loosely

[**] For instance, consider a software project requiring a one line
modification of gcc to build.  Assuming even that this one line is a
proper and non-contraversial fix for a gcc bug, gcc releases are
heavily checked for stability and released only periodically, so the
turnaround even given a swift review process will be long and also in
general unknowably long. The software project in question can, as a
patchwork fix, require its developers to apply the patch to their own
gcc source and build their own compiler to continue project
development.  However, this raises the bar to entry quite a bit,
skill-wise, time-wise, and psychologically. In addition, while
previously the project could require a particular OOTB version of gcc,
following the patch requirement, precise build instructions must be
provided and it will become difficult to diagnose what is going wrong
with particular compile errors.  All legacy developer environments
will be rendered non-working and all developers will have to apply the
same additional work to get a good development environment going
forward unless tools are provided.

[***] Open source is not unique in this particular position.  In fact,
the anti-marketing market is a large market.  Consider sales of Che
Guevera t-shirts, feminist literature from the traditional publishing
oligarchy, and Hollywood's marketing of the underdog.  In all of these
cases, that which is being peddled is -- symbolically and sometimes
literally -- in direct philosophic conflict with the marketeer. The
market, however, cares only to the degree that this is
perceived as an existential threat (which is usually not at all), and
subversion may be safely sold and counted only in terms of dollars. If
the Recording Industry Association of America ever needed a slush
fund, it could easily gain an buffer by selling plain white cotton
T-shirts emblazoned with the logo: "Destroy the RIAA".

[****] The question itself is intentionally flawed

[*****] There is the case where (a) programmer(s) intentionally
(conciouslly or subconciously) will set up a consulting firm
installing overly complex house-ware, charging for their expertise,
and then running.  While this does happen, it is not a major factor in
open source at large.