Loading ...
Sorry, an error occurred while loading the content.
 

Re: [decentralization] Common Source

Expand Messages
  • Zane Thomas
    Lucas, ... Got it. The democratic software public license purports to address the formula v. negotiation issue by effectively replacing negotiation with
    Message 1 of 23 , Jan 1, 2002
      Lucas,

      > 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.

      Zane
    • Todd Boyle
      ... That s right.. same as the Survivor series, or any legal or accounting partnership. Whenever you go down this road of Merit Shares, everything will be
      Message 2 of 23 , Jan 1, 2002
        At 09:19 PM 1/1/02, Zane Thomas wrote:
        >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

        That's right.. same as the Survivor series, or any legal or accounting
        partnership.

        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
        partnership behaviors.

        Todd
      • rahul@reno.cis.upenn.edu
        ... A completely democratic license creating all developers as equal partners would fail. The reason that co-operatives and franchises, which any such
        Message 3 of 23 , Jan 2, 2002
          > For example, there is no mechanism that would prevent the holders
          > 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.)

          A completely democratic license creating all developers as equal
          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
          presuure.

          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.
          >
          > 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.

          Agreed. Which is why the structure of the partnership quite decides its
          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.
          >
          >
          > 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.

          Transparency is a must, especially if renumeration is a volatile
          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.
          >
          > 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.
          >
          A transnational system would certainly be needed. One more thing:
          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
          risk..

          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.
          Rahul
        • Rikard Linde
          ... Practically, you can regard it as a hobby (although many programmers perceive coding as the most important part of their life). They have normal jobs and
          Message 4 of 23 , Jan 2, 2002
            > 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.

            Practically, you can regard it as a hobby (although
            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).

            Rikard

            _____________________________________________________
            Do You Yahoo!?
            se.yahoo.com
          • Todd Boyle
            ... The linux model establishes that the linux model is successful, but it does not disprove that a democratic model would fail. My impression, right now, is
            Message 5 of 23 , Jan 2, 2002
              At 07:43 AM 1/2/02, Rahul wrote:
              > > For example, there is no mechanism that would prevent the holders
              > > 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.

              The linux model establishes that the linux model is successful, but it
              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 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.

              Coders must surrender a hell of a lot in any large project. That's
              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 could
              > > 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.

              I suggest that a federation of partner's ledgers would operate
              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,

              Todd
            • Blair Zajac
              Michael, 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
              Message 6 of 23 , Jan 2, 2002
                Michael,

                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.

                Best,
                Blair

                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/
              Your message has been successfully submitted and would be delivered to recipients shortly.