Re: [Gnu-arch-users] GNU Arch moves to GPL v3 or later

[Thomas Lord]

Alfred M. Szmidt wrote:
> You might want to revise your history lesson about what Richard
> thinks. http://www.stallman.org/articles/xemacs.origin
>
> Hint, it had nothing to do with copyright assignments.
>   

It was a an early instance of a pattern that has proved reliable,
since those days:

A project (like Emacs) gets to a stage of development
that I'll dub "Immanent Maturity of Big New Features".
That means that the program gets to some stage where for
just increments of additional coding you get back leaps
of new value (like adding some graphical dodads to Emacs'
X interface).

Well, what is a software services open source company to
do when that happens -- when an interesting program
reaches the state of "Immanent Maturity..."?

At that stage, service firms want to "own" the program in
the sense that they would prefer to be the exclusive supplier
of the incremental improvements that create super-linear
new value.   If demand for that new value is high, and if
the service firm largely throttles which new increments are
done when, then the service firm can find ways to sell
that new value at a profit.

So: firms fork, essentially hostilely.   It happened to
Emacs, GCC, GDB, libc, Guile, Arch, Debian, GTk,
Gnome, .... probably others I'm forgetting.   These hostile
forks are usually not accompanied by a lot of strife (e.g.,
if a lead developer accepts a job then it is barely even noticed
that a fork took place).   In most cases, the corporate
forks win.   In the list above, Emacs and Guile are
exceptions and the jury is out on Debian.   This isn't obviously
bad -- it just *is*.

Software development projects in the public interest ought
to learn by now that, when they get far enough along, the
pressure for commercial forks will be high.    The strategies
and tactics of public projects have to learn to dance with
that devil, so to speak.

One way to go, in theory, is to close the "quality and
capability gap" between typical public and typical
commercial projects.    Maybe better software engineering
practices (e.g., better revision control) might lead to a point
at which it is always cheaper for the end-customers to buy
incremental improvements from the public project at labor-cost
than it would be to buy the same work from a corporate fork
at a premium.

Another way to go, in theory, is to start positioning public
projects upstream of The Inevitable Fork and basically to
try to monetize the process of technology transfer. 

The Corporate Forkers (an appellation one must type very
carefully) have already demonstrated, again and again,
that they are happy to pay a premium for technology
transfer.   They prove this when they hire project leads,
or entire project teams.   They prove it when they contribute
to NPOs around large projects.   They even prove it indirectly
with the demands they create for certain kinds of technical
documentation (e.g., the influence of an O'Reilley title).

The open question is how to structure public projects in such
a way that they can directly lay claim to some of that
premium payout rather than becoming the loser in a contest
for loyalties.

I haven't tried to define "public project" exactly and, when I
start talking about public projects that make money it invites
the question of what distinguishes corporate and public.  I'm
thinking of public projects as those whose technology is
fully free software, whose technology is transparent (publicly
accessible), whose primary business activity is creating
new software to add to their offerings, whose operators are
identified to and accessible to the public, and which make
no non-trivial service level guarantees to their paying
customers.   That is, I am thinking about those projects which
are the fountainheads of practical free software R&D.

Something like Gnome doesn't quite qualify, for example.
The technology may be largely transparent (or might not,
we don't really know).   The identity and accessibility of
operators is a debatable point.   But it is clear that most of
the primary operators of the project have plenty of private
contractual obligations that influence the direction of their
work.   It's a corporate rather than a public project because
its direction is partly determined by private service contracts
for private gain.   Compare that to how the Emacs project
runs....

So, how can a public project dance with the Corporate
Forkers?    It's an interesting question.    For one thing,
I think public projects need to go ".com," so to speak,
so that they can have a budget, a payroll, and official
customers.....   It's the last item in that list ("customers")
that advises against going ".org" (NPO).

-t