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

RE: [decentralization] Common Source

Expand Messages
  • Josh
    ... Good link. Thanks Jim. He also says If a company wants to redistribute Berkeley DB as a part of a proprietary product, they can come to Sleepycat and
    Message 1 of 23 , Dec 31, 2001
    • 0 Attachment
      > http://www.winterspeak.com/columns/102901.html

      Good link. Thanks Jim. He also says "If a company wants to redistribute
      Berkeley DB as a part of a proprietary product, they can come to Sleepycat
      and pay us a fee to purchase different license terms from us."

      Which is what we're going to do if we use that dbase, and we might use it
      for our project.

      What I don't like about the GPL the most is the ability to fork a project.
      If that can be contained so that forking can only happen with permission,
      then it would be a good fit for me. Such as "you may only fork the project
      if #1. its for a different platform, #2. your version remains interoperable
      with the other versions."

      > the trick is figuring out how to apply a dual-licensing scheme like
      > sleepycat's to a project with many contributors.

      I agree with you there. One idea I have is for a set # of shares,
      distributed among the programmers. As new contributions are made, some
      existing shares are equally distributed from each of the holders to the
      contributor. Because the # of shares is limited, and each holder must give
      up shares when compensation is desired, the group would be motivated to
      agree upon the distribution of the shares. Then whatever revenue is to be
      paid is in proportion to the shares of ownership. When money is needed to
      hire something built, the share distribution is used to cover the cost, so
      somebody who has 75% of the shares pay's 75% of the cost. But for loans that
      approach could get tricky (amortization).

      I think the more difficult part will be business decisions. A programmer
      working fulltime will have a different business mindset than a part time
      hobbyist, so sepration of revenue-for-work from business decisions is also
      necessary. I guess what I'm looking for is a traditional company or
      non-profit organization who's code is available for viewing, but not
      forking.

      Does anybody know of existing projects where these issues have been
      addressed?
      Another quote from that (very good) article:
      "Sleepycat couldn't exist if the current release of Berkeley DB were under
      the BSD license. I'm not taking a political stance, here -- I think that
      open source licenses like the GPL and the BSD license are valuable, and that
      both have created enormous value. As a business matter, though, the BSD
      license wouldn't allow Sleepycat to pursue the dual licensing strategy that
      we have with Berkeley DB. The business lesson here is that you need to
      consider your product strategy, your business model, and your licensing
      terms as a coherent whole. Our answers are embedded storage management,
      revenues from product licensing, and dual GPL/proprietary terms. If you
      change any one of those three, the business doesn't work anymore. "


      -----Original Message-----
      From: Jim Winstead [mailto:jimw-yahoo@...]
      Sent: Monday, December 31, 2001 7:02 PM
      To: decentralization@yahoogroups.com
      Subject: Re: [decentralization] Common Source

      On Mon, Dec 31, 2001 at 05:38:08PM -0800, Josh wrote:
      > Very nice job Michael! I thought I was the only one who saw GNU GPL as a
      > form of socialism. I respect what RMS has accomplished, but I don't
      believe
      > it's the right way for my project.
      >
      > [ snip ]
      >
      > As a person who's working on a hybrid business model and a hybrid license,
      > I'm very pleased to see this essay. It's about time somebody had the
      courage
      > to call it as it is.

      good grief. this brings up a good google groups challenge for someone:
      find the first person to accuse richard stallman of being a communist in
      a usenet post. i'd be shocked if it was any later than the mid-80s.

      and as michael olsen, ceo of sleepycat said in an interview, the terms
      of the sleepycat license are essentially identical with those of that
      dreaded gpl.

      http://www.winterspeak.com/columns/102901.html

      the trick is figuring out how to apply a dual-licensing scheme like
      sleepycat's to a project with many contributors. (that is, a
      decentralized one. look, we're almost back on-topic!)

      jim

      To unsubscribe from this group, send an email to:
      decentralization-unsubscribe@egroups.com



      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    • burton@openprivacy.org
      ... Hash: SHA1 ... OK... I will tear it apart :) ... Says who? You? I work on Open Source because I am greedy. Most of the project I work on WON T
      Message 2 of 23 , Jan 1, 2002
      • 0 Attachment
        -----BEGIN PGP SIGNED MESSAGE-----
        Hash: SHA1

        Michael Bauer <bauer@...> writes:

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

        OK... I will tear it apart :)

        ... here we go. please consider the following as *constructive* criticism.

        > Open Source and Free Software are neither open nor free. In fact, these
        > Orwellian terms masquerade clandestine exploitation. For too long the "free
        > and open" movements have been co-opted for political and personal
        > agendas. Like Marx and Lenin, RMS and ESR have convinced a whole generation of
        > developers that their work does not need to be their own, that it should be
        > shared for the common good and that the only compensation one should expect
        > should be the goodwill of the community and perhaps some small consulting
        > contracts

        <snip/>

        Says who? You? I work on Open Source because I am greedy. Most of the project
        I work on WON'T WORK IN THE PROPIETARY WORLD. My Jetspeed project would have
        never succeeded if it was proptietary. Companies like Epicentric were ahead of
        the game. Giving Jetspeed away to the public as Open Source made it a standard
        that others developed around. Eventually the big guns came in and backed me up
        (IBM, SAP, etc, etc).

        .. oh. and I did make a good deal of money off of the situation, just not from
        direct licensing. I made money by being an expert in a technology that was
        used in a lot of high places.

        Also, money doesn't have to be wrapped around EVERYTHING! Can't developers get
        together and work for something just for the fun of it?

        When you add money things get too political.

        You would be better asserting that it can't work without a more abundant
        economic backing. That I would buy....

        > In the meantime, companies are taking advantage of this naivete, developing
        > and selling derivative works and leaving open the question of whether
        > developers have been afforded due compensation. For developers to be truly
        > free and source to be truly open, new attitudes, organizations and mechansims
        > must be put in place to enable both developers and software to reach their
        > full potential - particularly in the business environment.

        No way. Most companies have to agree to the licenses. Even the ASF license
        has an advertising clause.

        If IBM doesn't give you want you need in WebSphere, just download Apache and go
        from there. They can't rape money out of an industry that can just DL the
        source from apache.org.

        > Frankly, it's time to view the open source software industry more like the
        > music industry - software is a copyrighted work and developers should be
        > entitled to royalties from their work. They should be able to get both kudos
        > and cash. The way to do this is through the creation of decentralized, open
        > "corporations". These open corporations should be based on new "common source"
        > licenses that protects the rights of developers and establishes royalty
        > streams for them in the case of commercialization of their software. Source
        > code can still be developed jointly and shared widely. It's just that the line
        > is drawn when people are going to start selling derivative works. Instead of
        > prohibiting this, the common source approach encourages it.

        You can do this now. Just license your code as GPL and offer an additional
        license for developers who want to ship binary only code. This is the way
        TrollTech ships their software and they are doing pretty good.

        ...

        OK. I am going to stop here.

        Get on the Free Software Business mailing list. fsb@...

        Your ideas are very conventional but don't map to the real world and the way
        Open Source really works.

        I would suggest boiling down each one of these paragraphs in a mailing to FSB
        and working from there.

        Kevin

        - --
        Kevin A. Burton ( burton@..., burton@..., burtonator@... )
        Location - San Francisco, CA, Cell - 415.595.9965
        Jabber - burtonator@..., Web - http://relativity.yi.org/

        Intellectual property does not exist! Get over it!
        -----BEGIN PGP SIGNATURE-----
        Version: GnuPG v1.0.6 (GNU/Linux)
        Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

        iD8DBQE8MYgYAwM6xb2dfE0RAgc/AKCjS6277IDParPOy1y60KOCXUqQugCgyjYW
        HNnVwTwO4k6vY5AZr/xkgqk=
        =hVwF
        -----END PGP SIGNATURE-----
      • burton@openprivacy.org
        ... Hash: SHA1 ... If the FSF is a form of socialism then what would you call the proptietary model. AKA Microsoft? This is MUCH worse. ... That is very far
        Message 3 of 23 , Jan 1, 2002
        • 0 Attachment
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1

          "Josh" <josh@...> writes:

          > Very nice job Michael! I thought I was the only one who saw GNU GPL as a form of
          > socialism. I respect what RMS has accomplished, but I don't believe it's the
          > right way for my project.

          If the FSF is a form of socialism then what would you call the proptietary
          model. AKA Microsoft? This is MUCH worse.

          > Quote: " For too long the "free and open" movements have been co-opted for
          > political and personal agendas. Like Marx and Lenin, RMS and ESR have
          > convinced a whole generation of developers that their work does not need to be
          > their own, that it should be shared for the common good and that the only
          > compensation one should expect should be the goodwill of the community and
          > perhaps some small consulting contracts. "
          >
          > As a person who's working on a hybrid business model and a hybrid license, I'm
          > very pleased to see this essay. It's about time somebody had the courage to call
          > it as it is.

          That is very far from the truth. Again... I would recommend that you join the
          FSB mailing list.

          <snip/>

          - --
          Kevin A. Burton ( burton@..., burton@..., burtonator@... )
          Location - San Francisco, CA, Cell - 415.595.9965
          Jabber - burtonator@..., Web - http://relativity.yi.org/

          For great justice.
          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.0.6 (GNU/Linux)
          Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

          iD8DBQE8MYibAwM6xb2dfE0RAtRtAKCqkEwJWUWKafGwweWw3dFP83npTwCgwaKx
          H+LOhajL9cwXqUnmtG7JBsc=
          =XvFc
          -----END PGP SIGNATURE-----
        • Lucas Gonze
          ... It s easy -- just ignore away all the complexities. Among which: 1) Approach to sharing royalties: divvy up
          Message 4 of 23 , Jan 1, 2002
          • 0 Attachment
            > > Quoth Jim Winstead on Monday, 31 December:
            > > : the trick is figuring out how to apply a dual-licensing scheme like
            > > : sleepycat's to a project with many contributors. (that is, a
            > > : decentralized one. look, we're almost back on-topic!)
            ...
            > i was referring to a system that resulted in the contributors
            > getting 'fairly' paid as part of the commercial side of that
            > dual-licensing arrangement.

            It's easy -- just ignore away all the complexities.
            <rolling-on-the-floor-laughing-at-own-joke/>

            Among which:
            1) Approach to sharing royalties: divvy up royalties on a per-line basis.
            Flaws: some lines are harder to write; incentivizes NIH within the source.
            2) Approach: divvy up royalties via code profiling so that lines in heavily used
            code pay off more. Flaws: incentivizes inefficient code.
            3) Approach: 1 coder == 1 share; divy up royalties in a pyramid scheme, where
            each new dev must be sponsored by an existing dev and each sponsoring dev takes
            a cut of sponsored devs royalties. Flaws: too numerous to mention.
            4) Approach: stop worrying and learn to love the bomb. Flaws: not getting to
            worry, loving the bomb.

            - Lucas
          • rahul@reno.cis.upenn.edu
            ... You might have to pick aspects of a product. For example, on a Linux distribution, you might leave the smaller non-desktop packages like binutils out of
            Message 5 of 23 , Jan 1, 2002
            • 0 Attachment
              >
              > It's easy -- just ignore away all the complexities.
              > <rolling-on-the-floor-laughing-at-own-joke/>

              You might have to pick aspects of a product. For example, on a Linux
              distribution, you might leave the smaller non-desktop packages like
              binutils out of such a scheme, but if you are sensible, unlike present
              distributors, you might package only 13-14 really good apps and have
              a team for each app that was rennumerated. How that renumeration would
              be split up on the app team would be up to the app leaders, or company
              providing the app. For example, if you included Ximian Evolution, a
              certain compensation from each sale would flow to Ximian.

              Now it might be said that this would be unfair to external contributors
              to Evolution. Well yes. There is no reasonable fair way to do that. But
              the point is, its not the app only which is being compensated for, it is
              the documentation, the changes to the app based on user testing that
              wouldnt have happened without the distributions investment, the support
              provided to the distribution users by application developers. There is
              lot of peripheral work needed around a basic GUI app like the improving
              of the text in the app to make it clear, the creating of app components,
              subtle changes to style and other things so that apps really have the
              same feel, interop work, etc. So in a sense its not just the app authors
              but the support crew which needs compensation too!

              If its not a company but an individual author, once again the choice of
              compensating such a team ought to be upto the author, within guidelines
              lain down by the distribution company to ensure that the additional
              needed work is done.

              Such a company would then be a distributed shell corporation, providing
              brand and some, but drastically reduced with respect to present
              companies, capital infrastructure, which I believe is a key cause for
              the present implosion ( see a recent essay I wrote,
              http://3pointo.nareau.com/stories/storyReader$4
              for more on that. Also, some extremely nice observations and
              convesations by Doc Searls at http://doc.weblogs.com/2001/12/30
              and links from there to Scripting News)

              The questions that Michael raised are somewhat broader, though, and
              directly releavant to this list. Will future corporations be distributed
              corporations? (Thoughts from the economist at:
              http://reno.cis.upenn.edu/~rahul/economist/Will_the_corporation_survive.pdf
              )
              Will open source projects, if thew want to be commercial entities, need
              to be distributed corporations? What are the characteristics of
              Distributed corporations? In both my essay and Michaels, there seem to
              be two identified processes necessary: Aggregation of contributors into
              a loosely coupled larger structure rather than a monolithic structure,
              and the incentivization of the contributors in monetary terms.
              What else?

              Rahul
            • Todd Boyle
              At 07:28 AM 1/1/02, Lucas Gonze enumerated 4 options. ... The democratic license seems to me, to be very similar to any other commercial partnership agreement.
              Message 6 of 23 , Jan 1, 2002
              • 0 Attachment
                At 07:28 AM 1/1/02, Lucas Gonze enumerated 4 options.

                >1) Approach to sharing royalties: divvy up royalties on a per-line basis.
                >Flaws: some lines are harder to write; incentivizes NIH within the source.
                >2) Approach: divvy up royalties via code profiling so that lines in
                >heavily used
                >code pay off more. Flaws: incentivizes inefficient code.
                >3) Approach: 1 coder == 1 share; divy up royalties in a pyramid scheme, where
                >each new dev must be sponsored by an existing dev and each sponsoring dev
                >takes
                >a cut of sponsored devs royalties. Flaws: too numerous to mention.
                >4) Approach: stop worrying and learn to love the bomb. [i.e. the GPL, I
                >presume]

                The democratic license seems to me, to be very similar to any other
                commercial partnership agreement. Anytime you have multiple
                independent developers, they would divvy up the rights in the code,
                in some fashion, and decide what rights to grant to the public. So
                the behaviors that will result from "democratic license" will be the
                same as existing, proprietary models.

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

                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.

                Oh yea. the reason I am posting is to suggest that accounting
                for Merit Shares is an appropriate application of an accounts receivable/
                accounts payable (AR/AP) ledger. Software collaborations between
                peers really calls for a partnership accounting system. The ledger of
                the partnership would accumulate the costs of the project itself during
                its development cycle, including any arbitrary set of timesheets,
                expense charges, flat fees, etc. The shares of ownership of the
                project presumably would be based on the partners' capital accounts
                plus amounts payable to partners. How those entries get on the
                books is always a matter for agreement between partners (just as it
                is with Democratic Software License)

                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.

                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.

                As a teaser, what happens when your partnership is legally domiciled
                in tax haven X, your webledger is in tax haven Y, the webledger of the
                partnership merit shares and finances are in Country 77, and your
                compiler is a robot server in Sealand, and the sales of the software
                on the web, in a widely diverse number of countries and currencies?
                Where is the income taxable? If you're a participant in projects 23, 44,
                and 66 and your merit shares went up and down, discontinuously
                on each of those projects as you invested code but your shares
                dropped each time others contributed code, then, if the big profitable
                project 500 sold $500 million in 44 countries and it was a rollup of
                22 projects which all had continously changing share fractions, then,
                how much income is taxable to you in YOUR country? Does it
                depend on how the Project 500 money was rolled up from those
                44 countries into its bank accounts in various jurisdictions? Does
                that answer depend on whether the money was distributed or
                retained by Project 500, or project 23, 44 or 66??

                Now, how much income would be taxable to you if you traveled
                extensively and the places where you did the work were also not
                continuous at all?

                Or what if Project 23 distributed shares in project 500 to you instead
                of money? etc. etc.

                Todd Boyle CPA 9745-128th Ave NE Kirkland WA
                tboyle@... 425-827-3107 website www.gldialtone.com
                employer www.netaccount.com project www.arapxml.net
              • rahul@reno.cis.upenn.edu
                ... Why dilute existing shereholders? One could think of two ways to not do that (a) UPO or uniform public offering is allowed by the SEC every year upto a
                Message 7 of 23 , Jan 1, 2002
                • 0 Attachment
                  >
                  > I agree with you there. One idea I have is for a set # of shares,
                  > distributed among the programmers. As new contributions are made, some
                  > existing shares are equally distributed from each of the holders to the
                  > contributor. Because the # of shares is limited, and each holder must give
                  > up shares when compensation is desired, the group would be motivated to
                  > agree upon the distribution of the shares. Then whatever revenue is to be
                  > paid is in proportion to the shares of ownership. When money is needed to
                  > hire something built, the share distribution is used to cover the cost, so
                  > somebody who has 75% of the shares pay's 75% of the cost. But for loans that
                  > approach could get tricky (amortization).
                  >
                  >
                  Why dilute existing shereholders? One could think of two ways to not do
                  that (a) UPO or uniform public offering is allowed by the SEC every year
                  upto a million dollars cap. This could be used as a way of getting
                  interested companies, such as IBM, or the community invest in a
                  project..its a mini special interest IPO if you like. What this does is
                  it increases the valuation of the company and now shareholders can loose
                  a fraction of their shares without being diluted
                  (b) The company holds some shares in escrow to be released on a yearly
                  basis. Its a capital investment the company makes, somewhat like a
                  company buying stocks to fullfill employee stock options buying (please
                  correct me if I am wrong, it isnt clear to be how stock options are
                  done)

                  Either way, one needs to increase valuation. In the first, valuation is
                  set by the market, in the second by investors.

                  But today, getting investors is the real problem. Just getting all the
                  developers who band together in this company to invest isnt enough,
                  unless the company is bootstrapped while everyone is doing other jobs,
                  so thats its initial capital expenses are very low, or the nature of the
                  business is such that it is, for example, a federation of businesses,
                  such as a co-operative consultancy for example. Even so, an increase in
                  valuation now depends upon profit or additional external investment.

                  But that may be the only way bootstrap is possible.
                  Rahul
                • Josh
                  (rahul wrote: ) ... Now that s a very useful bit of info. I m going to look into that before I talk to the next VC. Thanks. (todd wrote: ) ... Wow, very good
                  Message 8 of 23 , Jan 1, 2002
                  • 0 Attachment
                    (rahul wrote: )
                    > Why dilute existing shereholders? One could think of two ways to not do
                    > that (a) UPO or uniform public offering is allowed by the SEC every year
                    > up to a million dollars cap.

                    Now that's a very useful bit of info. I'm going to look into that before I
                    talk to the next VC. Thanks.

                    (todd wrote: )
                    > As a teaser, what happens when your partnership is legally domiciled
                    > in tax haven X, your webledger is in tax haven Y, the webledger of the
                    > partnership merit shares and finances are in Country 77....

                    Wow, very good points (beyond what I quoted). I think the solution is to
                    hire you to be the accountant!


                    Another thing I have to keep in mind is that my project won't be the type
                    that attracts a lot of developers & contributions, since it's not a program
                    / utility. As a mostly kernel mode infrastructure type of design, I'm
                    predicting that the size/power of the community that would/could form around
                    my project won't be that large in number. I'm starting to lean towards
                    expecting most contributions from employees. So I guess my comment is that
                    the power/effectiveness of the community, and therefore the open source
                    project itself, is directly tied to what type of project it is. The fact
                    that windows is the focus of the first version of my project even further
                    reduces the pool of talent that's able to contribute, and therefore drives
                    me more towards being a traditional company. Do any of you agree with this
                    assessment / "reality check"? My project is a network file system design.

                    - josh


                    -----Original Message-----
                    From: rahul@... [mailto:rahul@...]
                    Sent: Tuesday, January 01, 2002 11:56 AM
                    To: decentralization@yahoogroups.com
                    Subject: Re: [decentralization] Common Source

                    >
                    > I agree with you there. One idea I have is for a set # of shares,
                    > distributed among the programmers. As new contributions are made, some
                    > existing shares are equally distributed from each of the holders to the
                    > contributor. Because the # of shares is limited, and each holder must give
                    > up shares when compensation is desired, the group would be motivated to
                    > agree upon the distribution of the shares. Then whatever revenue is to be
                    > paid is in proportion to the shares of ownership. When money is needed to
                    > hire something built, the share distribution is used to cover the cost, so
                    > somebody who has 75% of the shares pay's 75% of the cost. But for loans
                    that
                    > approach could get tricky (amortization).
                    >
                    >
                    Why dilute existing shereholders? One could think of two ways to not do
                    that (a) UPO or uniform public offering is allowed by the SEC every year
                    upto a million dollars cap. This could be used as a way of getting
                    interested companies, such as IBM, or the community invest in a
                    project..its a mini special interest IPO if you like. What this does is
                    it increases the valuation of the company and now shareholders can loose
                    a fraction of their shares without being diluted
                    (b) The company holds some shares in escrow to be released on a yearly
                    basis. Its a capital investment the company makes, somewhat like a
                    company buying stocks to fullfill employee stock options buying (please
                    correct me if I am wrong, it isnt clear to be how stock options are
                    done)

                    Either way, one needs to increase valuation. In the first, valuation is
                    set by the market, in the second by investors.

                    But today, getting investors is the real problem. Just getting all the
                    developers who band together in this company to invest isnt enough,
                    unless the company is bootstrapped while everyone is doing other jobs,
                    so thats its initial capital expenses are very low, or the nature of the
                    business is such that it is, for example, a federation of businesses,
                    such as a co-operative consultancy for example. Even so, an increase in
                    valuation now depends upon profit or additional external investment.

                    But that may be the only way bootstrap is possible.
                    Rahul



                    To unsubscribe from this group, send an email to:
                    decentralization-unsubscribe@egroups.com



                    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                  • burton@openprivacy.org
                    ... Hash: SHA1 Lucas Gonze writes: ... I have thought about this in the past. Your above description is a a really good
                    Message 9 of 23 , Jan 1, 2002
                    • 0 Attachment
                      -----BEGIN PGP SIGNED MESSAGE-----
                      Hash: SHA1

                      "Lucas Gonze" <lucas@...> writes:
                      <snip/>

                      > Among which:
                      > 1) Approach to sharing royalties: divvy up royalties on a per-line basis.
                      > Flaws: some lines are harder to write; incentivizes NIH within the source.
                      > 2) Approach: divvy up royalties via code profiling so that lines in heavily used
                      > code pay off more. Flaws: incentivizes inefficient code.
                      > 3) Approach: 1 coder == 1 share; divy up royalties in a pyramid scheme, where
                      > each new dev must be sponsored by an existing dev and each sponsoring dev takes
                      > a cut of sponsored devs royalties. Flaws: too numerous to mention.
                      > 4) Approach: stop worrying and learn to love the bomb. Flaws: not getting to
                      > worry, loving the bomb.
                      <snip/>

                      I have thought about this in the past. Your above description is a a really
                      good breakdown but I think you are implying that you can only select one. This
                      isn't true. Select all 4 at the same time. :)

                      That and an efficient and distributed micro-payment system could really help Open
                      Source developers make spare cash.

                      - --
                      Kevin A. Burton ( burton@..., burton@..., burtonator@... )
                      Location - San Francisco, CA, Cell - 415.595.9965
                      Jabber - burtonator@..., Web - http://relativity.yi.org/

                      Whenever there is a conflict between human rights and property rights, human
                      rights must prevail.
                      -- Abraham Lincoln
                      -----BEGIN PGP SIGNATURE-----
                      Version: GnuPG v1.0.6 (GNU/Linux)
                      Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt

                      iD8DBQE8MkYgAwM6xb2dfE0RAp+TAJ9/mrx/pT5yrPGkOEq4jojztyaqSACgsbbj
                      mKhvOb0ChC997qoHkc+q2IM=
                      =vUSo
                      -----END PGP SIGNATURE-----
                    • Zane Thomas
                      Lucas, ... In the small software company I m part owner of we have always worked on a author-royalty basis. For small projects - that s most of them since we
                      Message 10 of 23 , Jan 1, 2002
                      • 0 Attachment
                        Lucas,

                        > 4) Approach: stop worrying and learn to love the bomb. Flaws: not getting to
                        > worry, loving the bomb.

                        In the small software company I'm part owner of we have always worked on a author-royalty basis. For small projects - that's most of them since we have been selling components to other programmers - one author does the whole job and gets all of the royalties. We have also collaborated with a few people working on a single project. For that we scope out the project, break it up into pieces, and negotiate percentages of the royalties. Also, because I have to oversee the development processes and because I like to search out new areas to explore developing in, I usually end up negotiating a percentage of royalties with someone else who takes over maintenance and enhancements. This has worked well for a few people at a time.

                        Zane
                      • Lucas Gonze
                        ... Yeah, that strikes me as completely cluesome, Zane, and it s pretty much the only solution I can think of, but there s no way to apply it here. An open
                        Message 11 of 23 , Jan 1, 2002
                        • 0 Attachment
                          > In the small software company I'm part owner of we have always worked
                          > on a author-royalty basis.

                          Yeah, that strikes me as completely cluesome, Zane, and it's pretty much the
                          only solution I can think of, but there's no way to apply it here.

                          An open source license is a statement of terms written before the fact of any
                          external contributions. If the license is all there is, and it has to be
                          because only copyright gives control to open source founders, then the valuation
                          method for contributions has to be something that you can state in advance. It
                          has to be a formula, and a formula is the opposite of a negotiation.

                          - Lucas
                        • Zane Thomas
                          Lucas, ... Got it. The democratic software public license purports to address the formula v. negotiation issue by effectively replacing negotiation with
                          Message 12 of 23 , Jan 1, 2002
                          • 0 Attachment
                            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 13 of 23 , Jan 1, 2002
                            • 0 Attachment
                              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 14 of 23 , Jan 2, 2002
                              • 0 Attachment
                                > 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 15 of 23 , Jan 2, 2002
                                • 0 Attachment
                                  > 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 16 of 23 , Jan 2, 2002
                                  • 0 Attachment
                                    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 17 of 23 , Jan 2, 2002
                                    • 0 Attachment
                                      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.