Re: [decentralization] Common Source
> An open source license is ...Got it.
The "democratic software public license" purports to address the formula v. negotiation issue by effectively replacing negotiation with dictate by an "executive committee" which is elected by "the authors" (ie. those whose contributions have been accepted by the committee).
I see a couple of potential problems with that proposed solution:
1. People who submit contributions under the terms of the license, at least as I understand it, give up their rights to the submitted material in advance of learning how many - if any - "merit shares" they might receive.
2. The executive committee is elected by a majority of shares, not authors. That seems to have a strong potential to create a feedback loop where those who have a majority of shares will elect themselves and make decisions which increase the number of shares they have, thus effectively excluding new authors from gaining enough power to gain a fair share. [this couldn't be too blatant or potential authors could form a similar effort of their own]
I wouldn't work under either of those conditions, since it would be just about the same as working for any Big Co without the prior negotiation of a known salary.
Personally I've never understood the open source "movement" - perhaps because I haven't really tried hard enough. I always wonder where the people writing open source code are getting the money they need to pay their rent. And it seems obvious that companies which attempt to maximize their profits would be more than happy to acquire as much free software as they can while contributing as little as they need to, which may be only as much as is required to keep key programmers feeling like they're making a contribution to a better world.
- At 09:19 PM 1/1/02, Zane Thomas wrote:
>2. The executive committee is elected by a majority of shares, notThat's right.. same as the Survivor series, or any legal or accounting
>authors. That seems to have a strong potential to create a feedback loop
>where those who have a majority of shares will elect themselves and make
>decisions which increase the number of shares they have
Whenever you go down this road of Merit Shares, everything will be fairly
harmonious as long as the software is not highly valuable.
As soon as the software is potentially worth a lot of money there will
*USUALLY* be some battle, sooner or later, to sell rights probably
exclusively under within section 5.13 and sec. 7.0, and get the money
distributed the money to holders of merit shares.
http://www.dsf.org.uk/dspl11.html This is not necessarily a bad thing,
it's just the way things work.
The more I read this, the more convinced I become that you cannot be a
little bit pregnant. If the license is anything other than the GPL or
other pure open source, then, you're back to ordinary commercial
> For example, there is no mechanism that would prevent the holdersA completely democratic license creating all developers as equal
> of the merit shares from bickering exactly like any other partnership
> of sovereign parties (partnerships are notorious for engendering a lot
> of bickering, and wasting tremendous time as each partner is
> required to maintain an encyclopedic complete model of every economic
> decision of the entity in order to protect their own interests, etc.)
partners would fail. The reason that co-operatives and franchises, which
any such distributed model would mimic to some degree do well is that
each separate unit, here a code module or an app in the distributed
linux distribution case, are separately managed with their own systems,
and ultimately a committee of leaders, or an elected or self-appointed
subset of these leaders does the decision making.
A great example can be found in the management of the linux distribution
itself by Linus and his lietenants. The meritocracy establishes who this
lietenants are, and everyone abides by them due to sheer community
Thats why app leaders or main developers arent a bad choice, they have
the "community" capital to make the decisions. And decision making
cannot be completely democratic..but how well a linux like model would
work in the business world is an open question. It is definitely worth
a try tho.
>Agreed. Which is why the structure of the partnership quite decides its
> For example, this idea "Merit Shares shall be allocated by the Executive
> Committee " at http://www.dsf.org.uk/dspl11.html sec. 5.3, implies
> some kind of unilateral power that doesn't exist. Any developer,
> understanding the code could anticipate directions the product
> must go in order to succeed. They could write those predictable
> routines and refuse to release them to the project unless they get
> extortionately high merit points. Having seen all the code, the
> other developers would face legal hurdles if they try to build around
> it. I don't know. I am just speculating. I've seen a lot of commercial
> partnerships. The results are not always pretty.
propensity for success for failure. And the granularity of the effort is
important. It is not clear to me that individual apps would work in such
a model, unless the model is a consultancy, and the app large enough,
like apache. A distribution of linux apps, or servers may be a better
bet. Ofcourse, there could be various federation models where a largely
independent apache oriented business federates with a linux distribution
to be included in it as an add on, but with a different revenue
distribution from the other parts of the distribution. The success of
unbundling may be important here..if a distribution provides everything
it does not engender a good third party or federated economy around it.
>Transparency is a must, especially if renumeration is a volatile
> The achilles heel of many partnership systems in the past has been
> the complexity of integration with the partner's private accounting
> systems.. Basically all the complexity was shoe horned through the
> form K-1 at the end of the year, and any ideas of transparency or
> drilldown during the year were out of the question! But if you incorporated
> partnership accounting in a system like Sourceforge, it could also
> maintain the webledgers of the developers. Developers could be in
> many projects, and all the entries for all the projects would be posted
> by the same webledger host. So, everything always balances.
combination of a base plus a performance oriented part. I'd say, in any
open corporation, gross financials of the actors involved would need top
be open to all. While this may or may not entail a webledger, the actors
finances as they deal with other actors would need to be open. How open
are the actors own ledgers to its own components ought to once again be
a local decision, especially if the actors are heterogeneous, as in say
the individual developer of a particular application and a company which
develops another. A corollary is that such a model might work best if
the actors themselves are small companies.
>A transnational system would certainly be needed. One more thing:
> Any multicurrency partnership accounting system (and there are MANY)
> could today, provide a foundation for a collaboration infrastructure,
> by maintaining participation balances in a currency of Merit Shares,
> and ordinary charges and credits in ordinary currencies. I think this
> is the way forward, in distributed development ventures.
establishing valuations. In a distributed model this is hard. There are
two aspects of this: asset capital, and asset potential capital (the
latter typicall is done by VC's or the market). Such valuation would be
important for the purposes of issuing shaares and raising capital.
Other interesting issues arise in selling. What if I want to quit
developing an app. How do I hand it over? There could be a tangible
asset handover to a company, or a non-tangible handover to another group
or person in the same group.
One point arises again and again
here which has been made by Hernando de Soto in the
case of third world economies. There, the poor possess a lot of dead
capital, as in lack of property titles.
In the commercial software world, code is property, and thus there is an
explicit model for legal trading of code in takeovers, etc. In open
source, the code is given away through license, so there is no capital
associated with it. What these conversations are saying is, for those
who convert this free code to their capital(Red Hat), there perhaps ought
to be a price. Put another way, one needs to pay for intellectual
capital, if one is to sustain it wholesale.
The issues arent easy. What about day jobs? Insurance? Bootstrapping
with little capital. Ultimately maybe some sort of free agency notions
are needed with the aggregation precisely for issues such as insurance
and market power..but perhaps indeed time can be used as a firstorder
decider of share distribution, since in such cases, time translates to
Open source development will happen with or without business, Its a
labor of love for the developers. The first attempt at commercialization
has failed. It is time to experiment with other models to see if they
will be any more successfull.
> Personally I've never understood the open sourcePractically, you can regard it as a hobby (although
> "movement" - perhaps because I haven't really tried
> hard enough. I always wonder where the people
> writing open source code are getting the money they
> need to pay their rent.
many programmers perceive coding as the most important
part of their life). They have normal jobs and code in
their free time (a normal job that means they have
between eight and ten hours every day to code).
Do You Yahoo!?
- At 07:43 AM 1/2/02, Rahul wrote:
> > For example, there is no mechanism that would prevent the holdersThe linux model establishes that the linux model is successful, but it
> > of the merit shares from bickering exactly like any other partnership
> > of sovereign parties (partnerships are notorious for engendering a lot
>A completely democratic license creating all developers as equal
>partners would fail... A great example can be found in the management
>of the linux distribution itself by Linus and his lietenants. The meritocracy
>establishes who this lietenants are, and everyone abides by them due to
>sheer community presuure.
does not disprove that a democratic model would fail.
My impression, right now, is that http://www.dsf.org.uk/dspl11.html
is close enough to a "completely democratic" model to serve as a
test case. So, let's see how well it succeeds!
Our discussion cannot really proceed until somebody can point to
examples of large "Democratic" projects that have succeeded. Until
then, it remains sort of a theoretical thing.
>Thats why app leaders or main developers arent a bad choice, they haveCoders must surrender a hell of a lot in any large project. That's
>the "community" capital to make the decisions. And decision making
>cannot be completely democratic..but how well a linux like model would
>work in the business world is an open question. It is definitely worth
>a try tho.
intrinsic to being in a large software project.
The cycles they burn on coding decisions are already 100% of their
mental capacity. If they have to consider partnership gamesmanship,
the code will be paralyzed and would OF COURSE be sub-optimal,
measured against technical requirements.
All good code today requires the coder to surrender to their team
inside a commercial software company, or surrender to their team
in an open source model. There's no "collaboration" or partnership
model, featuring the Coder as a sovereign independent businessman!
But it's possible. The Coder might surrender to the team, same as
the other models. Everybody would invest their trust in the partnership
accounting or merit shares scheme, instead of the company or "Linus".
> > Any multicurrency partnership accounting system couldI suggest that a federation of partner's ledgers would operate
> > maintaining both participation balances in a Merit currency,
> > and monetary balances in ordinary currencies....
>A transnational system would certainly be needed. One more thing:
>establishing valuations. In a distributed model this is hard.
independently, and any member could compose and submit *any*
offer to any other member(s). Basically, a developer might create
an expense report or claim for merit shares, etc. to the partnership,
or to a bunch of partners. This transaction would be drafted in
the form of an actual accounting entry. If the recipient or recipients
replied by affixing their digital signatures then it would be marked
as 'approved' and the sovereign ledgers would know, this is a
good, final transaction. Nobody needs to surrender any sovereignty
or any privacy whatsoever. See http://www.gldialtone.com/STR.htm
if you're interested in this choreography, this project sucked up
about 1000 hours of work by three guys in 1999 and we thought
it was pretty solid, conceptually, in multiparty transactions,
A good read.
A couple of minor points:
1) I would include Sleepycat software in the table. It's the first company
I looked for.
2) Can you make the table fit to the browser width, otherwise when printing,
the right side of the table is chopped.
Michael Bauer wrote:
> I've put together an essay for which I'd like some feedback. It's a call
> for a new look at open source and free software, one I call Common Source.
> Essentially, the piece articulates why traditional open source business
> models don't work for the most part and why it's time for a new way of
> developing shared source code. I advocate the creation of decentralized
> "open corporations" based on a new "common source" license. These
> corporations more effectively manage copyright. The license enable
> developers to more effectively exploit commercial opportunities. The
> essay contains an analysis of about 40 open source companies - sort of
> before the dotcom bust and afterwards.
> You can find the article at
> http://www.michaelbauer.com/common-source.html. It's a draft so please,
> tear it apart. Thanks!
Blair Zajac <blair@...>
Web and OS performance plots - http://www.orcaware.com/orca/