Buzilla and RPM as a platform for project funding -- A Strawman

Version 0.0 - Michael Tiemann

The "bug bounty" model for funding open source development has, so far
as I can tell, been a miserable failure.  There are many possible
explanations for this failure:

1.  People don't want to feel like they are paying ransom for problems
    they report.

2.  In situations where bugfixes are urgently needed (and expected), one
    should have an existing relationship of trust, not depend on
    creating a new one in the heat of the moment.

3.  For every bug that bothers people, there are probably 100 bugs they
    don't even know about.  These bugs are often just as important, if
    not directly related to, the bug in question.

4.  The design of a bug-bounty system frames software development as a
    banaged-based approach.  Linus never said that with enough bandages,
    all wounds are shallow.

The approach of this proposal is a design to leverage some familiar
aspects of open source development, but to organize them in a way that
encourages greater innovation and quality than the current ad hoc model.

The first aspect of the design is to recognize that Upstream is where
the action is.  Indeed, Red Hat's own development stragegy is to do as
much as possible with upstream developers in order to maximize the
utility of our own contributions.  Experience has proved again and again
that significant development done on a branch leads to bit-rot in the
short run and fewer bad feelings in the long-run.

Most Upstream projects run quite well without any control from Pick Your
Favorite Vendor.  Nevertheless, many upstream projects would likely
welcome a mechanism that gave them tangible resources--specifically
money--to help with the project, as long as that mechanism didn't
require significant changes to the day-to-day operations of the project.

The second aspect of the design is to recognize that RPM has provided a
way of versioning, relating, and cataloging thousands of upstream
projects.  Upstream projects like the Linux Kernel or the KDE Project
have thousands of contributors, but very often the fruits of those
projects are not tangible to users until they are actually installed on
some system.  RPM is a way denoting what version, packaging, etc., a
user is using, and provides a concrete vocabulary of values and
aspirations between producers and consumers.

The third aspect of this design is to recognize that the Bugzilla
database provides a mechanism to relate specific issues (bugs and/or
features) to specific packages (generic/upstream or versions,
architectures, etc) and relate those issues to other issues (which may
block or depend upon the issue in question).  Last year Bugzilla was
enhanced so that issues opened at bugzilla.redhat.com could be related
to issues in upstream projects.  The mechanism keeps the integrity of
upstream development while allowing users to speak in package terms with
which they are familiar.

The fourth aspect of this design is to provide an adminstrative
mechanism so that users (bugzilla account holders) can apply resources
(money they contribute to the Fedora Foundation) to a wide range of
projects and issues and then see an accounting of their investments and
results.  For users, this aspect is expressed as a client program (which
could be a web-based client) that is modeled after stock and bond
portfolio analysis tools, but which track open source resource
allocation instead.

Some potential views of the client include:

Funded Projects: projects that are actively selected for funding.  Shows
dates and amounts of funding (percentage and absolute), cumulative
funding vs. cumulative funds (over selected date ranges), available
funds, project funding rank, project rating (user-defined), etc.  This
is like a portfolio analysis tool for those who invest in stocks and
bonds.

Funding Candidates: projects not yet funded, but which are
"interesting".  Shows cumulative contributions by the community (over
selected date ranges), available funds, project funding rank, project
rating (user-defined), etc.  If you are thinking about funding a project
but are not yet ready to commit, this is like a watch list for stocks
and bonds.

Project Relationships: shows how selected projects are related to other
projects via RPM relationships.  Partcularly interesting as open source
becomes more application-oriented, because more and more packages wind
up being in one mix or another.

Collections: Looks at projects in the context of collections (such as
Fedora Core, Fedora Extras, Damn Small Linux, etc).

This design trivially implements part of the "Bug Bounty" system by
allowing users to direct specific funds to be applied to specific
issues.  The design does not trivially allow users to hold developers
accountable to finishing tasks or to condition release of funds on the
attainment of a particular goal, but those are not key goals to the
design.

But instead of talking about non-goals, let us look at how this design
plays out for accomplishing some specific goals from the user's (not
developer's) perspective.

My top three extra-curricular open source interests (in no particular
order) are:

1.  The GRASS Project (open source GIS)

2.  The kde edu Project (primarily kstars and kiten)

3.  The Blender Project (open source 2D and 3D content generation)

The GRASS Project has many dependencies, some optional and some not.
The optional ones add all sorts of cool features like 3D visualization,
comprehensive statistical analysis, and easy-to-use graphical
interfaces.  The GRASS Project supports deep integration with some other
high-profile and mainstream projects: PostgreSQL, The R Project, and
Perl, for example.

For my purposes, I want GRASS developers to have the resources and
motivations to keep the platform moving forward, but I also want to keep
the integration between GRASS and other top-level projects working
smoothly.  And I want my GRASS RPM packages timely as new versions of
Fedora come out.  Thus, if I wanted to divide up my funding for GRASS, I
might allocate as follows:

50% GRASS (root: grass-*.src.rpm)
25% R Project (root: R-*.src.rpm)
25% PostgreSQL Project (root: postgresql-*.src.rpm)

and refine that as follows:

30% Core GRASS Development (root: grass-*.src.rpm)
10% GRASS Packaging for Fedora (root: grass-*.fd5.src.rpm)
2.5% GRASS Interfaces to R
2.5% GRASS Interfaces to sp
5% GRASS Interfaces to PostgreSQL

10% Core R Project (root: R-*.src.rpm)
10% R Spatial Project (root: sp-*.src.rpm)
5% R Interfaces to GRASS

10% Core PostgreSQL Project (root: postgresql-*.src.rpm)
10% PostGIS Project (root: postgis-*.src.rpm)
5% Postgres Interfaces to GRASS/PostGIS

If I treat that as my "GRASS Allocation", then for every $1.00 I invest
into that allocation, $0.30 will go to the core GRASS project and $0.05
will go to Postgres Interfaces to GRASS/PostGIS.

There are already several issues that this design makes obvious.  The
first, and most obvious, is that my favorite GRASS rpm is not known to
Red Hat's bugzilla database.  But I see this not as a failure of the
design, but a failure of collaboration, at least as far as the Fedora
Foundation is concerned, for how can the Fedora Foundation support
projects that don't have any official Fedora presence?

The second is that relationships that I care about--integration between
GRASS and other top-level projects--are not directly supported by
bugzilla.redhat.com nor, necessarily, by RPM.  After all, how can RPM
know that I've installed R so that I can use it with GRASS?  Answer: it
cannot, but it doesn't need to.  What the system does need to be able to
do is to be able to reference two packages and then create and label
relationships between those two packages.  A huge amount of art goes
into creating and maintaining the dependencies between components that
have /necessary/ dependencies (for example, the fact that grass-6.1
depends on libpq.so.4 which is provided by postgresql-libs-8.0.3-1PGDG),
but these other dependencies can be created by the user and and
consistently communicated to all developers.

The third is that there are many components in the GRASS world that I'm
not contributing to directly.  How will those components benefit?  What
about the people who package libraries that GRASS depends upon like fftw
or gdal or libstdc++?  The answer is choice: the user has the choice
about how discrete they want to be in partitioning their funds, and
developers, too, should have choice in their upstream and downstream
dependencies.  A third choice is to let the system suggest alternatives
for finely dividing up the resources.  The system could offer allocation
suggestions for sending resources to `rpmquery --requires` (better
infrastructure), `rpmquery --whatrequires` (more user demand), or
suggest projects that are within the given package's dependency
hierarchy based on metrics such as other funding (increased network
effect around financially successful projects), popularity (another way
to increase network effect), popularity divided by funding (send money
to popular margins but don't fund the rich guys), etc.  Over time, users
would probably get a fairly good feeling about how to browse for and
fill need among the projects they care about most.

Let's turn now to a second project I'd like to help fund: kstars.
Kstars is a desktop planetarium for KDE.  It can also control an
external telescope (via serial cable) so I can click on an object and
then see what it looks like in real life.

My problems with kstars range up and down the software stack.  Sure,
there are some problems with the UI that I'd like to see fixed and some
features I'd like to see added.  But consider this problem: kstars
offers several different themes for presenting the night sky.  One,
called "Star Chart" is like a standard star chart one might take
outside: it's a white background with dark stars whose sizes correspond
to their visual magnitude.  The brighter the star, the larger it is.  So
far so good, but while one would take an actual star chart outside at
night, one would never illuminate it with white light--it would destroy
one's night vision (which is something like 10,000x more sensitive than
our normal day vision).  Instead, astronomers use red light that does
not destroy the chemicals that makes our eyes so sensitive at night.
kstars also has a "Night Vision" theme, which is a black background
(well, dark grey because the LCD screen only has 100:1 contrast) and red
stars.  With the screen dimmed to its lowest level, it's OK until
there's a dialog box to be dismissed.  When the dialog box is dismissed,
kstars lets it go and then something, maybe it's the GNOME desktop,
maybe it's the X Window system, maybe its the video driver, lets it
display in pure white before it disappears.  This momentary blink /is/
enough to destroy night vision.  I believe this makes a strong case for
a resource allocation system that can range from the desktop application
to the graphics device drivers of a given computer.

Blender is a wicked cool 3D modeling and animation package.  Tools like
blender have one foot in the real world (architectural modeling) and one
foot in the fantasy world (where anything is possible, and the laws of
physics are whatever you want to define).

GRASS has the ability to import 2d and 3d objects and layer them into
other 2d and 3d datasets.  With GRASS it is possible to import a 3d
model of New York City and lay it down on the USGS elevation data for
the island of Manhattan.  With Blender it would be possible to model and
place King Kong at the top of the virtual empire state building, use US
Census data to know how many Young, Upwardly mobile Professionals might
be able to leave their desks to save the city within a 5 block radius,
and then use NVIZ to actually see the monkey, the city, and the
statistics in a 3d flyover.

Blender can also be used to model the Universe, and then start to play
with various phyical parameters.  What if everything in kstars was
logarithmically closer?  What if light decayed linearly instead of
quadratically?  What would it look like if Sirius went supernova?  What
would the night sky look like if there were 10,000 stars in our local
cluster instead of 10 or 20?  Yes, there are stellar simulation programs
like Celestica, but blender lets you define all the rules, not just
break one (the speed of light).

So Blender is cool, but what's complex about the money?  Well, for one,
Blender is not the only creative tool in town.  GIMP is a paint program
that's indispensible if you want to create textures for Blender models.
There are some cool open source Renderman renderers one can plug in as
well.  All of this, again, fits together as a constellation of technical
resources.  I believe that a system that allows one to contribute to the
whole, rather than just the few entities set up to take money, should
increase the quality of the whole.

In each of these three cases, there are some other key dimensions that I
have not yet discussed: localization and accessibility.  Each of the
three programs I mentioned make English a first-class language, but not
all users of open source are fluent in English.  Localization is
certainly an area where a little funding, consistently applied, can go a
long way.  Accessibility is also an important subject, and while there
is some concentrated effort to supporting accessibility at some
infrastructural level, there's nothing like ensuring that a given
project is focusing resources on how accessible their application can
be.

Let's now turn to the developer's perspective.  A great many open source
projects are blessed with a number of committed volunteers who do the
work, day in and day out.  Some of these volunteers are "sponsored" by
companies; that is, their salary is paid to basically do what's needed
to be done.  But there are also many who are working on projects for
fun, or who would have time to contribute if they could just earn a
little more money doing it.  Since the goal of the overall design is to
increase the capacity of the open source community, the developers we'll
focus on are those who are working for their own interests, not
exclusively for sponsorship money.

In the proprietary software world, every developer draws a salary, and
every salary fits into a budget, and every budget must fit some top-down
model.  Thus, in the proprietary world, options are limited (by the
finite size of the budget), and many worthwhile objectives are sidelined
because there is simply no way to fit them into the budget.  In the open
source software world, developers always have the option to work on a
problem, it's just a question of whether or not they, individually, have
the resources to do so.  The existence of an funding agency does not
limit the work that can be done in open source software--it expands it.

In an ideal world, the only thing slowing developers down is the
challenge of the technical problem they're hacking.  When open source
software developers need to take time out of their day to find money or
take time out of their day to juggle other resources, value is lost.
What is an efficient way for developers to make these non-technical
issues known?  And what is an effective way to ensure that the right
resources are going to the right people?

One way to do this is to create a web of trust and then only flow money
as far as the trust goes.  The Fedora Project already has a contributors
agreement that's been signed by hundreds if not thousands of people.
These agreements create a web of trust related to copyright, patent,
trademark, and trade secret issues as well as export controls and some
other legal requirements.  People who don't want to sign those
agreements are not forced do, and they can still write open source
software, they just don't have the chance to contribute directly to
Fedora.  In a similar way, a financial agreement could set conditions
for receiving money from the Fedora Foundation.  People who agreed to
uphold those conditions could act as agents for their projects, and
could work to bring others into the process, just as contributors are
encouraged to recruit other contributors.

Thus, this web of trust mechanism puts the following forces into some
form of equilibrium balance:

1.  A willingness on behalf of users to offer $$ with intentions
    (not contracts) attached

2.  A willingness of projects to join this web of trust

3.  A desire of users to fund increasingly fine-grained aspects of
    intra- and inter-project development

4.  A motivation for developers to become increasingly transparent in
    terms of needs and results

There is a bit of a test case for such a design in the world of funding
public school education: donorschoose.org.  In the past three years,
donorschoose.org has received over $5M in donations that have gone to
benefit 300K students.  90% of the donations come from people who
identified themselves as first-time philanthropists, and the average
donation size is around $200.  The design of that system is about as
fine-grained as you can imagine: yes, you can search for schools in your
state, district, schools where X% of the students get Federal assistance
for lunch or Y% speak English as a second language, but at the end of
the day, every donation is earmarked for a specific classroom's specific
educational need: rugs for kindergardeners, calculators for precal
students, a tablesaw for the drama class (a request that I chose to
fulfill), etc.  If there are 25,000 open source users with $200 to spend
on their specific (or general) issues, that's $5M of resource waiting to
be allocated, and $5M that's highly unlikely to get to the right place
if all just bought distribution CDs from distributor A, B, or C.

M