--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/toolbox-blog.txt	Tue May 19 20:08:52 2015 -0700
@@ -0,0 +1,199 @@
+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.