Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Doobs]

I was under the impression that code of the following form :

X : <Some Type>;
Y : <Some Type>;
for Y'Address use X'Address;

would result in an overlay in the resulting code.   However on a project 
where external test equipment showed that the contents of  X were NOT the 
same as Y I investigated further.  I checked on both a Windows host version 
of GCC (3.4.2) and a target cross compiler (GCC 3.4.4) and on both the 
construct above is actually implemented using indirection (a pointer).  The 
map file and symbol table show that irrespective of the data type and size 
of Y it is always implemented as a pointer to X.  Although this appears 
semantially identical to an overlay as far as the progam is concerned it is 
NOT identical as far as an external observer is concerned.    I have a bit 
packed record which I wanted to return as an array of longwords to pretty 
dumb test equipment. The easiest way *would* be to overlay a longword 
array - however this would not appear to be possible.....
 

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Jeffrey Creem]

Doobs wrote:
> I was under the impression that code of the following form :
> 
> X : <Some Type>;
> Y : <Some Type>;
> for Y'Address use X'Address;
> 
> would result in an overlay in the resulting code.   However on a project 
> where external test equipment showed that the contents of  X were NOT the 
> same as Y I investigated further.  I checked on both a Windows host version 
> of GCC (3.4.2) and a target cross compiler (GCC 3.4.4) and on both the 
> construct above is actually implemented using indirection (a pointer).  The 
> map file and symbol table show that irrespective of the data type and size 
> of Y it is always implemented as a pointer to X.  Although this appears 
> semantially identical to an overlay as far as the progam is concerned it is 
> NOT identical as far as an external observer is concerned.    I have a bit 
> packed record which I wanted to return as an array of longwords to pretty 
> dumb test equipment. The easiest way *would* be to overlay a longword 
> array - however this would not appear to be possible.....
>  
> 
> 

Try applying pragma volatile to both declarations. Also for completeness 
you should add a pragma import to Y to avoid any default initialization.

There is an AI that talks (to some exent) to this issue.

I am not entirely sure that the volatile will fix your problem because I 
  don't quite get what the resulting behaviour is that you are 
seeing/not seeing.

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Doobs]

">> I was under the impression that code of the following form :
>>
>> X : <Some Type>;
>> Y : <Some Type>;
>> for Y'Address use X'Address;
>>
>> would result in an overlay in the resulting code.

>>
>
> Try applying pragma volatile to both declarations. Also for completeness 
> you should add a pragma import to Y to avoid any default initialization.
>
> There is an AI that talks (to some exent) to this issue.
>
> I am not entirely sure that the volatile will fix your problem because I 
> don't quite get what the resulting behaviour is that you are seeing/not 
> seeing.

Tried Pragma volatile - had no effect.....

What I am seeing is that in the map file X and Y are located at different 
addresses.  Even though Y is a large array in my implementation, the linker 
has only reserved four bytes for it.  When examining the contents of Y at 
run time it contains the address of X - i.e. it is a pointer to X

What I actually want is that Y and X are physically located at the same 
address (i.e. a true overlay) so that test equipment that uses the symbol 
table to resolve data can look at X and resolve the contents as one data 
type or look at Y and resolve the contents as another - but they are 
physically reading the same memory.  I dont want the run-time overhead of 
copying the contents via unchecked conversion to another data type.

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Florian Weimer]

> I was under the impression that code of the following form :
>
> X : <Some Type>;
> Y : <Some Type>;
> for Y'Address use X'Address;
>
> would result in an overlay in the resulting code.

Could you show some more code?  Probably initialization is causing
your problems, which can be fixed with a pragma Import.

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Doobs]

"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
news:87odzl5ilt.fsf@mid.deneb.enyo.de...
>> I was under the impression that code of the following form :
>>
>> X : <Some Type>;
>> Y : <Some Type>;
>> for Y'Address use X'Address;
>>
>> would result in an overlay in the resulting code.
>
> Could you show some more code?  Probably initialization is causing
> your problems, which can be fixed with a pragma Import.

The following is an example of the problem:

package TestPackage
is

   type MyRecordType is
   record
      element1 : Positive;
      element2 : Positive;
   end record;

   type MyArrayType is array(1..2) of Positive;

   myX : MyRecordType;
   pragma volatile(myX);
   myY : MyArrayType;
   pragma volatile(myY);
   for myY'Address use myX'Address;


end TestPackage;

The following fragments of the resulting MAP file (GCC 3.4.2 mingw32) show 
the problem...

 .data          0x00472b00       0x10 ./testpackage.o
                0x00472b00                testpackage__myy
 .data          0x00472b10       0x10 ./nextpackage.o

<..... later in the file...>

 COMMON         0x004a2770       0x20 ./testpackage.o
                0x004a2770                testpackage__myx
                0x004a2780                testpackage_E


Clearly myX and myY do NOT share the same address.  I am also puzzled as to 
why the variables have been put in differen memory sections... 

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Martin Krischik]

Doobs wrote:

>  I dont want the run-time overhead of
> copying the contents via unchecked conversion to another data type.

Actually the compiler is free to optimize away the copy in unchecked
conversion. In fact: the compiler can optimize away any variable which a
vanilla declaration. i.E. not declared with any extra like "aliased", for
'Address, pragma volatile etc. pp.

Martin
-- 
mailto://krischik@users.sourceforge.net
Ada programming at: http://ada.krischik.com

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Dmitry A. Kazakov]

On Sat, 1 Apr 2006 17:52:46 +0100, Doobs wrote:

> ">> I was under the impression that code of the following form :
>>>
>>> X : <Some Type>;
>>> Y : <Some Type>;
>>> for Y'Address use X'Address;
>>>
>>> would result in an overlay in the resulting code.
> 
> Tried Pragma volatile - had no effect.....
> 
> What I am seeing is that in the map file X and Y are located at different 
> addresses.  Even though Y is a large array in my implementation, the linker 
> has only reserved four bytes for it.  When examining the contents of Y at 
> run time it contains the address of X - i.e. it is a pointer to X

Is it possible that the object's type is unconstrained and what you see is
the array dope allocated at the address specified, rather than the array
body?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Doobs]

"Doobs" <doobs@doobs.com> wrote in message 
news:SdmdndA2Z9jbI7PZnZ2dnUVZ8qWdnZ2d@pipex.net...
>
> "Florian Weimer" <fw@deneb.enyo.de> wrote in message 
> news:87odzl5ilt.fsf@mid.deneb.enyo.de...
>>> I was under the impression that code of the following form :
>>>
>>> X : <Some Type>;
>>> Y : <Some Type>;
>>> for Y'Address use X'Address;
>>>
>>> would result in an overlay in the resulting code.
>>
>> Could you show some more code?  Probably initialization is causing
>> your problems, which can be fixed with a pragma Import.
>
> The following is an example of the problem:
>
> package TestPackage
> is
>
>   type MyRecordType is
>   record
>      element1 : Positive;
>      element2 : Positive;
>   end record;
>
>   type MyArrayType is array(1..2) of Positive;
>
>   myX : MyRecordType;
>   pragma volatile(myX);
>   myY : MyArrayType;
>   pragma volatile(myY);
>   for myY'Address use myX'Address;
>
>
> end TestPackage;
>
> The following fragments of the resulting MAP file (GCC 3.4.2 mingw32) show 
> the problem...
>
> .data          0x00472b00       0x10 ./testpackage.o
>                0x00472b00                testpackage__myy
> .data          0x00472b10       0x10 ./nextpackage.o
>
> <..... later in the file...>
>
> COMMON         0x004a2770       0x20 ./testpackage.o
>                0x004a2770                testpackage__myx
>                0x004a2780                testpackage_E
>
>
> Clearly myX and myY do NOT share the same address.  I am also puzzled as 
> to why the variables have been put in differen memory sections...
>
Note that including a pragma import did NOT solve the problem - the code 
looked like this

   myX : MyRecordType;
   pragma volatile(myX);
   myY : MyArrayType;
   pragma volatile(myY);
   for myY'Address use myX'Address;
   pragma Import (Ada, myY);


But the map file exhibited the same problem as before. 

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Jeffrey Creem]

Doobs wrote:
> "Doobs" <doobs@doobs.com> wrote in message 
> news:SdmdndA2Z9jbI7PZnZ2dnUVZ8qWdnZ2d@pipex.net...
> 
>>"Florian Weimer" <fw@deneb.enyo.de> wrote in message 
>>news:87odzl5ilt.fsf@mid.deneb.enyo.de...
>>
>>>>I was under the impression that code of the following form :
>>>>
>>>>X : <Some Type>;
>>>>Y : <Some Type>;
>>>>for Y'Address use X'Address;
>>>>
>>>>would result in an overlay in the resulting code.
>>>
>>>Could you show some more code?  Probably initialization is causing
>>>your problems, which can be fixed with a pragma Import.
>>
>>The following is an example of the problem:
>>
>>package TestPackage
>>is
>>
>>  type MyRecordType is
>>  record
>>     element1 : Positive;
>>     element2 : Positive;
>>  end record;
>>
>>  type MyArrayType is array(1..2) of Positive;
>>
>>  myX : MyRecordType;
>>  pragma volatile(myX);
>>  myY : MyArrayType;
>>  pragma volatile(myY);
>>  for myY'Address use myX'Address;
>>
>>
>>end TestPackage;
>>
>>The following fragments of the resulting MAP file (GCC 3.4.2 mingw32) show 
>>the problem...
>>
>>.data          0x00472b00       0x10 ./testpackage.o
>>               0x00472b00                testpackage__myy
>>.data          0x00472b10       0x10 ./nextpackage.o
>>
>><..... later in the file...>
>>
>>COMMON         0x004a2770       0x20 ./testpackage.o
>>               0x004a2770                testpackage__myx
>>               0x004a2780                testpackage_E
>>
>>
>>Clearly myX and myY do NOT share the same address.  I am also puzzled as 
>>to why the variables have been put in differen memory sections...
>>
> 
> Note that including a pragma import did NOT solve the problem - the code 
> looked like this
> 
>    myX : MyRecordType;
>    pragma volatile(myX);
>    myY : MyArrayType;
>    pragma volatile(myY);
>    for myY'Address use myX'Address;
>    pragma Import (Ada, myY);
> 
> 
> But the map file exhibited the same problem as before. 
> 
> 

Try this.

package TestPackage
is

    type MyRecordType is
    record
       element1 : Positive;
       element2 : Positive;
    end record;

    type MyArrayType is array(1..2) of Positive;

    myX : MyRecordType;
    pragma Volatile(Myx);
    Pragma Export(Ada, Myx, "MyX");

    myY : MyArrayType;
    pragma Volatile(Myy);
    pragma Import(Ada, Myy, "MyX");

end TestPackage;

Not sure exactly what your end desired result is but assuming you really 
need to do this then perhaps this works.

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Dmitry A. Kazakov]

On Sat, 1 Apr 2006 19:19:48 +0100, Doobs wrote:

> "Doobs" <doobs@doobs.com> wrote in message 
> news:SdmdndA2Z9jbI7PZnZ2dnUVZ8qWdnZ2d@pipex.net...
>>
>> "Florian Weimer" <fw@deneb.enyo.de> wrote in message 
>> news:87odzl5ilt.fsf@mid.deneb.enyo.de...
>>>> I was under the impression that code of the following form :
>>>>
>>>> X : <Some Type>;
>>>> Y : <Some Type>;
>>>> for Y'Address use X'Address;
>>>>
>>>> would result in an overlay in the resulting code.
>>>
>>> Could you show some more code?  Probably initialization is causing
>>> your problems, which can be fixed with a pragma Import.
>>
>> The following is an example of the problem:
>>
>> package TestPackage
>> is
>>
>>   type MyRecordType is
>>   record
>>      element1 : Positive;
>>      element2 : Positive;
>>   end record;
>>
>>   type MyArrayType is array(1..2) of Positive;
>>
>>   myX : MyRecordType;
>>   pragma volatile(myX);
>>   myY : MyArrayType;
>>   pragma volatile(myY);
>>   for myY'Address use myX'Address;
>>
>>
>> end TestPackage;
>>
>> The following fragments of the resulting MAP file (GCC 3.4.2 mingw32) show 
>> the problem...
>>
>> .data          0x00472b00       0x10 ./testpackage.o
>>                0x00472b00                testpackage__myy
>> .data          0x00472b10       0x10 ./nextpackage.o
>>
>> <..... later in the file...>
>>
>> COMMON         0x004a2770       0x20 ./testpackage.o
>>                0x004a2770                testpackage__myx
>>                0x004a2780                testpackage_E
>>
>>
>> Clearly myX and myY do NOT share the same address.  I am also puzzled as 
>> to why the variables have been put in differen memory sections...
>>
> Note that including a pragma import did NOT solve the problem - the code 
> looked like this
> 
>    myX : MyRecordType;
>    pragma volatile(myX);
>    myY : MyArrayType;
>    pragma volatile(myY);
>    for myY'Address use myX'Address;
>    pragma Import (Ada, myY);
> 
> But the map file exhibited the same problem as before.

Hmm, with gnat 3.15p for Windows (no any pragmas) it gives:

    0x00414848                testpackage__myy
    0x0041484c                testpackage__myx

which seems to be fine, assuming MyY's dope. Both

   MyX.element1'Address = MyY (1)'Address
   MyX.element2'Address = MyY (2)'Address

evaluate true.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Doobs]

>>>>>I was under the impression that code of the following form :
>>>>>
>>>>>X : <Some Type>;
>>>>>Y : <Some Type>;
>>>>>for Y'Address use X'Address;
>>>>>
>>>>>would result in an overlay in the resulting code.
>>>>
>>>>Could you show some more code?  Probably initialization is causing
>>>>your problems, which can be fixed with a pragma Import.
>>>
>>>The following is an example of the problem:
>>>
>>>package TestPackage
>>>is
>>>
>>>  type MyRecordType is
>>>  record
>>>     element1 : Positive;
>>>     element2 : Positive;
>>>  end record;
>>>
>>>  type MyArrayType is array(1..2) of Positive;
>>>
>>>  myX : MyRecordType;
>>>  pragma volatile(myX);
>>>  myY : MyArrayType;
>>>  pragma volatile(myY);
>>>  for myY'Address use myX'Address;
>>>
>>>
>>>end TestPackage;
>>>
>>>The following fragments of the resulting MAP file (GCC 3.4.2 mingw32) 
>>>show the problem...
>>>
>>>.data          0x00472b00       0x10 ./testpackage.o
>>>               0x00472b00                testpackage__myy
>>>.data          0x00472b10       0x10 ./nextpackage.o
>>>
>>><..... later in the file...>
>>>
>>>COMMON         0x004a2770       0x20 ./testpackage.o
>>>               0x004a2770                testpackage__myx
>>>               0x004a2780                testpackage_E
>>>
>>>
>>>Clearly myX and myY do NOT share the same address.  I am also puzzled as 
>>>to why the variables have been put in differen memory sections...
>>>
>>
>> Note that including a pragma import did NOT solve the problem - the code 
>> looked like this
>>
>>    myX : MyRecordType;
>>    pragma volatile(myX);
>>    myY : MyArrayType;
>>    pragma volatile(myY);
>>    for myY'Address use myX'Address;
>>    pragma Import (Ada, myY);
>>
>>
>> But the map file exhibited the same problem as before.
>
> Try this.
>
> package TestPackage
> is
>
>    type MyRecordType is
>    record
>       element1 : Positive;
>       element2 : Positive;
>    end record;
>
>    type MyArrayType is array(1..2) of Positive;
>
>    myX : MyRecordType;
>    pragma Volatile(Myx);
>    Pragma Export(Ada, Myx, "MyX");
>
>    myY : MyArrayType;
>    pragma Volatile(Myy);
>    pragma Import(Ada, Myy, "MyX");
>
> end TestPackage;
>
> Not sure exactly what your end desired result is but assuming you really 
> need to do this then perhaps this works.

Interestingly with this approach any reference to myY disappears from the 
Map file and debug symbol table.
myY then ceases to be a useful symbol for debugging purposes external to the 
program  (which was the original reason to have the overlay!).....

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Gerd]

Why not use an overlayed record for your data, something like this:

procedure Overlay is  -- your X
   type
      Sometype is record
         x: integer;
         y: integer;
        end record;

   type
      Othertype is array (1..2) of Integer;  -- your Y

   type
      OVL (b: Boolean) is record
        case b  is
          when true => s : Sometype;
          when false => o : Othertype;
        end case;
      end record;

   for OVL use record
                  s at 0 range 0..63;
                  o at 0 range 0..63;
                  b at 8 range 0..7;
               end record;

  data : OVL ( b=>true ); -- data with Y and X at the same address
        
begin
  null;
end Overlay;

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Randy Brukardt]

"Doobs" <doobs@doobs.com> wrote in message
news:LIednWDbPNgXGbPZRVnysQ@pipex.net...
> I was under the impression that code of the following form :
>
> X : <Some Type>;
> Y : <Some Type>;
> for Y'Address use X'Address;
>
> would result in an overlay in the resulting code.

It does, semantically.

>...   Although this appears
> semantially identical to an overlay as far as the progam is concerned it
is
> NOT identical as far as an external observer is concerned.   I have a bit
> packed record which I wanted to return as an array of longwords to pretty
> dumb test equipment. ...

I fail to understand why it would matter. If you have "dumb test equipment",
it clearly knows nothing about Ada. So you are just looking at bare dumps of
information; in that case, why not just use X and forget that Y exists?
Treat Y as an artifact of the program, not a "real* entity. If the equiment
is smart enough to know about Ada type information (or be told about Ada
type information), then it must be smart enough to handle the indirection
here and there should be no problem.

In any case, your requirement is far out of the norm. Your best bet is to
contact the vendor (AdaCore) in this case and get their advice. Yes, that
means paying for support; but this is the kind of requirement that falls
under custom support anyway. (Surely that would be our answer if you asked
us how to make our compiler do this.) Expecting unusual requirements to be
handled for free on important projects is just plain silly.

                                  Randy.

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Justin Gombos]

On 2006-04-04, Randy Brukardt <randy@rrsoftware.com> wrote:
>
> Expecting unusual requirements to be handled for free on important
> projects is just plain silly.

The best support is often free.  I see no issue with the OP using this
forum as a starting point.  

In fact, it would be beyond silly to start up a support contract for a
single issue, risking the possibility that the paid support can't help
anyway, when the issue could potentially be answered in a public forum
at no cost.

The OP came to the right place.  If the forum fails to help, he still
has the option of buying support.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer?

[Randy Brukardt]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:PJi_f.1717$7Z6.1073@trnddc06...
> On 2006-04-04, Randy Brukardt <randy@rrsoftware.com> wrote:
> >
> > Expecting unusual requirements to be handled for free on important
> > projects is just plain silly.
>
> The best support is often free.  I see no issue with the OP using this
> forum as a starting point.

Neither do I. But that wasn't my point. He appears to have business critical
requirements on a product. You cannot expect to have those handled for free.

> In fact, it would be beyond silly to start up a support contract for a
> single issue, risking the possibility that the paid support can't help
> anyway, when the issue could potentially be answered in a public forum
> at no cost.

Absolutely true; if he has business critical needs, he should have started a
support contract long ago. Waiting until you're blocked to try to arrange
for help is a major schedule risk -- especially if getting the approval for
a support contract takes several levels (as is typical).

This discussion highlights one of problems (maybe the only real problem)
with the typical open source model. It relies on selling support to generate
the revenues needed to support the development. (Developers need to eat!)
But truly great software does not need support at all (no bugs, intuitive to
use, etc.), and probably requires little training. (I consider a support
call an indication of failure.) So, it appears that open source (at least
the traditional model) is incompatible with truly great software. [Before
you all start a flame-war, please note that commercial closed source
development also has pressures at odds with truly great software - in
practice, it hasn't delivered it, either. It's conceivable that no model
could deliver it in practice...which is very sad.]

Free support can be very effective with great software - but if there is too
much of it, the software will inevitably fall into disrepair.

                      Randy.

Making money on open source, if not by selling _support_, then how?

[Marc A. Criley]

This seems like an interesting tangent off the "Re: Any way of 
persuading GNAT/GCC to implement a true overlay and not a pointer?" 
topic, so let's branch off...  :-)

Randy Brukardt wrote:

> This discussion highlights one of problems (maybe the only real problem)
> with the typical open source model. It relies on selling support to generate
> the revenues needed to support the development. (Developers need to eat!)
> But truly great software does not need support at all (no bugs, intuitive to
> use, etc.), and probably requires little training. (I consider a support
> call an indication of failure.)

I basically agree with Randy here.  If the software is truly great, as 
he defines it (no bugs, intuitive to use, and I would add acceptable 
performance), then the need for "traditional" support to report bugs and 
find out how to work around them is gone, and if one knowledgeable in 
the application domain finds the software intuitive to use, then again 
the need for support to figure out how to do something is gone.

So how does the developer of a potentially great open source (or even 
proprietary) product justify the need for a customer to buy support from 
the developer?

One area is providing support for the problem domain, not just the 
product, i.e. consulting.  AdaCore does this, and I expect RR does as 
well for their customers.  While the expert in the problem domain may 
find the product intuitive and not need support, most product's users 
are not experts, and will find themselves looking for help in solving 
their problem with the aid of your product, where your (the developer's) 
expertise becomes valuable.  If your product is capable of assisting the 
customer is solving their problem in your product's application domain, 
then it's reasonably likely you have a good structural understanding of 
that domain.  (This also depends on the complexity of the problem 
domain, you probably won't find much need for support in the domain of 
cutting 2x4s to length, but will in distributed, fault-tolerant 
applications.)

Another area for support isn't so much "support" as it is maintenance 
and upgrades.  This of course runs the risk of adding features of 
marginal value, just so you can say the software is now "better" and 
more capable.  Creeping featurism is a well-known issue in this 
industry, and most people know what can result from that--just look at 
the mature products of a certain large productivity applications and 
operating system company.  Another variant of this can almost be viewed 
as "changing things for the sake of changing them."  If you've ever 
installed an upgrade of a product and remarked that some feature you've 
always used now works, or is accessed, differently and that "it was 
perfectly fine the way it was", then you know what I'm talking about.

Once a program is saturated with the necessary features, and they work 
well together and operate efficiently, i.e., the software is "great", 
there's no justification for changing them or adding more, and therefore 
there's no justification for software support on that basis.

So if your software is great, and is well- and thoughtfully featured, 
and you want to keep developing software, what can you actually do to 
your product to justify customer support?

What I've seen, and been involved in, both in my professional career and 
in my own personal activities, is that often the software can be the 
basis of a "family" of products.  Instead of increasing the "density" of 
features by adding or changing them, increase the breadth of 
applicability.  E.g., if your programming tool only handles Ada, add 
support for C++ and Java; if your command and control system does launch 
planning for a specific type of missile, add support for other kinds, 
and then other types of weapons; if your text processor handles 
well-structured, but non-standardized text formats, add explicit support 
for XML.

This can of course get out of hand ("when all you have is a hammer, 
every problem looks like a nail"), but if you were capable of writing 
great software (in all the aspects of "greatness") in the first place, 
you ought to be able to tell what problems domains it makes sense to 
expand your software's functional breadth into.

 > So, it appears that open source (at least
> the traditional model) is incompatible with truly great software.

Ehn, okay, maybe with the "traditional model", but that's a very narrow 
support model.


-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-11, Marc A. Criley <mcNOSPAM@mckae.com> wrote:
>
>> So, it appears that open source (at least the traditional model) is
>> incompatible with truly great software.
>
> Ehn, okay, maybe with the "traditional model", but that's a very
> narrow support model.

I believe Randy was talking specifically about *profitable* open
source software.  When developing open source for non-profit, you
could not come closer to a model that promotes trully great software.
First of all, there are no conflicts of interest.  You don't need to
sell support, or sell the next bug fix.  You can work proudly on "your
baby" without the profit driven incentives that force you to release
something that's substandard.

Introducing profit is what creates a disincentive to produce trully
great software, regardless of whether it's open or closed source.
Randy may not accept this, but the negative impact on quality is much
more pronounced with closed source because the company producing the
product is necessarily the same organization that sells the support.

With open source, a support organization may have a disincentive to
improve the quality of the product, but other users and organizations
don't have the same disincentive.  Open source decentralizes control
over all these variables, which enables the tools to become trully
great.  Open source support organizations are then forced to offer a
trully great service, because they cannot rely on software
deficiencies the way closed source organizations do.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-11, Marc A. Criley <mcNOSPAM@mckae.com> wrote:
>
> What I've seen, and been involved in, both in my professional career
> and in my own personal activities, is that often the software can be
> the basis of a "family" of products.  Instead of increasing the
> "density" of features by adding or changing them, increase the
> breadth of applicability.  E.g., if your programming tool only
> handles Ada, add support for C++ and Java; if your command and
> control system does launch planning for a specific type of missile,
> add support for other kinds, and then other types of weapons; if
> your text processor handles well-structured, but non-standardized
> text formats, add explicit support for XML.

That's a good point.  This is another case where consumers of closed
source software get shorted.  Increasing breadth in the Bill Gates
model usually means reproducing something that already exists, so the
vendor can sell something to the customer that they already have.
Consequently closed source buyers end up paying for the same
functionality many times over because the code is not shared between
the producers.  The Richard Stallman (GNU) model enables developers to
focus on their small piece because the interfacing pieces are freely
available.  So this matter of efficiency (not having to spend time
reinventing) promotes better quality open source software.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Tue, 11 Apr 2006 15:13:31 GMT, Justin Gombos wrote:

> First of all, there are no conflicts of interest.

Is it good to have no conflicts? I would say, what we have now is rather a
lack of [technological] conflicts and true competition. Technical
superiority is long not an issue.

[...]

I agree with Randy. There are two fundamental problems neither model
actually responds:

1. Rewarding true inventors (rather than monopolists, publishers,
investors, lobbyists etc.)

2. Selecting targets of public interest (70% of software isn't needed
independently on its quality.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 11 Apr 2006 15:13:31 GMT, Justin Gombos wrote:
>
>> First of all, there are no conflicts of interest.
>
> Is it good to have no conflicts? 

Absolutely.  If the goal is quality software, conflicting interests
hinder quality, by definition.  

> I would say, what we have now is rather a lack of [technological]
> conflicts and true competition. Technical superiority is long not an
> issue.

That's pretty vague.  Would you clarify?  What do you mean by "what we
have now"?

> I agree with Randy. There are two fundamental problems neither model
> actually responds:
>
> 1. Rewarding true inventors (rather than monopolists, publishers,
> investors, lobbyists etc.)

There are intrinsic rewards with creating GNU software.  When you say
"rewarding" here, are you talking purely in terms of remuneration
(that is, extrinsic rewards)?

I must say folks have lost sight of the purpose of copyright.
Contrary to popular belief, copyrights did not emerge for the purpose
of rewarding producers of creative works.  That's only the means.  The
purpose of copyright is not to "put food on the table" (as Randy might
say), but it is to get creative works to the public.  The intended
beneficiary is everyone participating in society.  The role of
copyright was purely to use artificial incentives as a /means/ for
artists/creators to produce.  The consumers only had to give up their
right to copy (in a time period when no consumer a viable way of
copying books).  So people gladly gave up rights that they could not
exercise anyway; which was a reasonable deal at the time.

Copyright has recently turned into something that actually *reduces*
the distribution of creative works to the public.  It has been
perverted to reward a few (excessively), and punish those who fail to
contribute -- when such extrinsic rewards are not needed to motivate
the creation in the first place.

Copyright history deviates from the topic, but it had to be clarified
whether rewarding the inventor is a means or an end.  Ultimately
you're saying that failing to reward true inventors is a problem, but
that's only a problem to the extent that such a failure inhibits works
from being produced.  Yet GNU software exists, so where's the problem?

Moreover, if quality software is the goal, the traditional model is
inadequite.  The contemporary copyleft GNU type model is better suited
for this.  To illustrate, you can figure that Microsoft products were
strictly produced under Bill Gates cathedral (closed) software model.
Now compare the quality of those products to the quality of GNU tools.
Need I say more here?

> 2. Selecting targets of public interest (70% of software isn't needed
> independently on its quality.)

What do you mean by this?

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

Justin Gombos wrote:
> On 2006-04-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>>On Tue, 11 Apr 2006 15:13:31 GMT, Justin Gombos wrote:
>>
>>
>>>First of all, there are no conflicts of interest.
>>
>>Is it good to have no conflicts? 
> 
> 
> Absolutely.  If the goal is quality software, conflicting interests
> hinder quality, by definition.  

Which definition is that?

Re: Making money on open source, if not by selling _support_, then how?

[Randy Brukardt]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:z5S_f.4049$XI6.1174@trnddc05...
> There are intrinsic rewards with creating GNU software.  When you say
> "rewarding" here, are you talking purely in terms of remuneration
> (that is, extrinsic rewards)?

I don''t see any reason to restrict the intrinsic rewards to "GNU software".
I've stuck with Ada (despite the high probablity that I could make more
money doing something else) simply because I find Ada better, more fun, etc.
than the alternatives.

But that doesn't provide a means of support. No matter what benefits to
overall society there are, if the individual creators cannot support
themselves, they'll have to do something else. Which means no creations at
all.

It's this argument that tars "open source" with the "communist" label (since
that is the only way to decouple means of support from the act of creating
software). And, in any case, it's unrealistic. I don't see any intrinsic
reason that "open source" has to be incompatible with capitalism, but it's
quite important that the creators get some of the rewards. In the current
world, it is the leeches of the world (marketers, lawyers, etc.) that get
most of the money; the creators get little of it. Open source seems to
change that equation to ensure that the leeches get *all* of the money. (I
presume that's the *real* reason it has become popular...)

I'm less concerned about that in cases where there is no money (such as most
Ada utilities libraries). 100% or 0% of nothing is still the same amount...

                              Randy.

Re: Making money on open source, if not by selling _support_, then how?

[Ed Falis]

On Tue, 11 Apr 2006 15:59:54 -0400, Randy Brukardt <randy@rrsoftware.com>  
wrote:

> Open source seems to
> change that equation to ensure that the leeches get *all* of the money.


Damn, now I'm a leech.

- Ed

Re: Making money on open source, if not by selling _support_, then how?

[Steve]

"Marc A. Criley" <mcNOSPAM@mckae.com> wrote in message 
news:292bf$443bb4e4$45491254$20549@KNOLOGY.NET...
[snip]
> ... you probably won't find much need for support in the domain of cutting 
> 2x4s to length, but will in distributed, fault-tolerant applications.)
>

You obiously don't understand the complexity of cutting 2x4's to length.  In 
todays sawmills boards sometime scanned at a rate that exceeds 120 board per 
minute.  In that 500 msec window a detailed surface model of the board must 
be scanned and analyzed for defects.  The defects may include vertical 
grain, knots, checks, blue stain and other defects.  The value of the end 
product may change significantly depending on how the board is trimmed.  In 
fact in some environment the complexity of the grading rules and potential 
products makes trimming lumber a good application for distrubuted 
processing.

Just when you thought you had found a good example of a simple task.

BTW: I don't program trimmers, but others in my department do, and I am 
familiar with what is involved.

Steve
(The Duck)

[snip]
>
>
> -- Marc A. Criley
> -- McKae Technologies
> -- www.mckae.com
> -- DTraq - XPath In Ada - XML EZ Out 

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Tue, 11 Apr 2006 17:56:47 GMT, Justin Gombos wrote:

> On 2006-04-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

>> I would say, what we have now is rather a lack of [technological]
>> conflicts and true competition. Technical superiority is long not an
>> issue.
> 
> That's pretty vague.  Would you clarify?  What do you mean by "what we
> have now"?

We have various monopolies which subsidize complete kinds of software with
others things. This effectively kills competition and technical progress.

>> I agree with Randy. There are two fundamental problems neither model
>> actually responds:
>>
>> 1. Rewarding true inventors (rather than monopolists, publishers,
>> investors, lobbyists etc.)
> 
> There are intrinsic rewards with creating GNU software.  When you say
> "rewarding" here, are you talking purely in terms of remuneration
> (that is, extrinsic rewards)?

Both. See Randy's answer.

[...]
> Copyright has recently turned into something that actually *reduces*
> the distribution of creative works to the public.

Yes, and it only supports the point. The copyright and patent systems do
not reward inventors. They do publishers.

> Yet GNU software exists, so where's the problem?

The problem is in the word "yet." GNU is a protest movement, protest
against the existing [bad] system, by people who have money earned
elsewhere. I don't see how this can solve the problem. Is it the idea that
the flight-control software should be developed by welfare recipients? The
crux is funding. Funding from support is inherently corrupt, I agree with
Randy.

> Moreover, if quality software is the goal, the traditional model is
> inadequite.  The contemporary copyleft GNU type model is better suited
> for this.  To illustrate, you can figure that Microsoft products were
> strictly produced under Bill Gates cathedral (closed) software model.
> Now compare the quality of those products to the quality of GNU tools.
> Need I say more here?

Scientific questions aren't decided by voting. Everything depends on who is
the priest in the cathedral. It can easily turn to an orgy.

>> 2. Selecting targets of public interest (70% of software isn't needed
>> independently on its quality.)
> 
> What do you mean by this?

The system feeds itself. Go to any software store and ask yourself, if all
these products were for free, would you take time to install them. With the
software written on customer demand, it is even worse. It is probably 80%
of software which is not needed, and even damaging to customer's core
business.

Probably the software market should be regulated, as one of mass
consumption products. At least the fundamental rule - no liability, no pay
- should be enforced. That should let some air out of the bubble...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

On Wed, 2006-04-12 at 10:32 +0200, Dmitry A. Kazakov wrote:

>  Is it the idea that
> the flight-control software should be developed by welfare recipients?

It is the idea that flight-control software will be developed
by paid programmers ("they need to eat!"), whatever the license or
"openness" can be. What RMS seems to have had in mind is a system
of rewards distribution (money). There are similar systems of reward
distribution for works of art. At least in the country where you
and I live these are well known organizations. They do fund those
who under current circumstances find less "buyers" than their
colleagues. (There are flaws in this system.) A reason is that
pricing for works of art is, uh.., highly volatile and contingent
independent of quality and effort.

So if you appreciate what your less successful colleagues produce,
you help by alleviating the effect the current market has on their
income, in a collaborative, yet distant way.
(van Gogh didn't have to starve because he was supported(!) by family
relations.) Actually, you don't have to like your competition. Still,
I would feel much better if people understood that each of us
can make a living when the others can do that, too.


And besides, open source is not necessarily the same thing as
GNU software. In fact, even many of the GPLed programs are not GNU
software.

>  The
> crux is funding. Funding from support is inherently corrupt, I agree with
> Randy.

It might be of advantage to the discussion if you clarify what you mean
by "support", as others have tried already.


> Scientific questions aren't decided by voting. Everything depends on who is
> the priest in the cathedral.

The "priest" may well depend on votes.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-11, Georg Bauhaus <bauhaus@futureapps.de> wrote:
> Justin Gombos wrote:
>> On 2006-04-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> 
>>>On Tue, 11 Apr 2006 15:13:31 GMT, Justin Gombos wrote:
>>>
>>>
>>>>First of all, there are no conflicts of interest.
>>>
>>>Is it good to have no conflicts? 
>> 
>> Absolutely.  If the goal is quality software, conflicting interests
>> hinder quality, by definition.  
>
> Which definition is that?

Conflict of interest.  For both interests to coexist, there must be a
compromise.  In this case, software quality is compromised.  So to
recap, it is favorable to have no conflict of interest so you don't
have to reduce quality.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-11, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
> news:z5S_f.4049$XI6.1174@trnddc05...
>> There are intrinsic rewards with creating GNU software.  When you say
>> "rewarding" here, are you talking purely in terms of remuneration
>> (that is, extrinsic rewards)?
>
> I don''t see any reason to restrict the intrinsic rewards to "GNU
> software".

Nor do I.

> But that doesn't provide a means of support. No matter what benefits
> to overall society there are, if the individual creators cannot
> support themselves, they'll have to do something else.

That's right.  Creators need to make money - but not necessarily off
their creations.  If they can, great!  

> Which means no creations at all.

You can't conclude that.  If that were a true statement, we would not
have the rich library of GNU software that exists today.  Why?
Because there's nothing to stop a GNU developer from having a day job.
I suspect most self supporting GNU developers have day jobs.

> I don't see any intrinsic reason that "open source" has to be
> incompatible with capitalism, but it's quite important that the
> creators get some of the rewards.

Sure, but the rewards don't have to be extrinsic.  Intrinsic rewards
are substantial enough to motivate open source development.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

Justin Gombos wrote:

>>>Absolutely.  If the goal is quality software, conflicting interests
>>>hinder quality, by definition.  
>>
>>Which definition is that?
> 
> 
> Conflict of interest.  For both interests to coexist, there must be a
> compromise.  In this case, software quality is compromised.  So to
> recap, it is favorable to have no conflict of interest so you don't
> have to reduce quality.
> 

Conflicting interests can also bring software production back on
track. How about this:
Sometimes programmers go astray and enjoy themselves writing
wonderfully sophisticated "high quality" Ada. Meanwhile the
toaster company goes out of business because their embedded
temperature sensors will be so great, when they will finally
arrive...

How could we possibly know which interest are the ones that make
us write the really great software products? What exactly is the one
interest in the set of conflicting interests that should dominate
because no compromise can be better?

Maybe there is not so much a compromising compromise but rather a
method of combining the various interests into a satisfying solution
to a problem. Presuming a problem is well defined, ever, in the real
world.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Wed, 12 Apr 2006 13:23:21 +0200, Georg Bauhaus wrote:

> On Wed, 2006-04-12 at 10:32 +0200, Dmitry A. Kazakov wrote:
> 
>> Is it the idea that
>> the flight-control software should be developed by welfare recipients?
> 
> It is the idea that flight-control software will be developed
> by paid programmers ("they need to eat!"), whatever the license or
> "openness" can be.

I definitely agree with "paid." The rest is easy who pays, how and for
what. (:-))

> I would feel much better if people understood that each of us
> can make a living when the others can do that, too.

So, basically it reads as follows: because our economical system cannot
handle it, we should turn to education, propaganda, religion to convince
people to share. I.e. a charity-driven developing rather than
welfare-driven one. Is it better?
 
>> Scientific questions aren't decided by voting. Everything depends on who is
>> the priest in the cathedral.
> 
> The "priest" may well depend on votes.

That would be a MP. A "priest" reports only to God or His personal
representative, the Dow Jones Industrial Average... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Larry Kilgallen]

In article <RI7%f.4698$7Z6.3710@trnddc06>, Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
> On 2006-04-11, Georg Bauhaus <bauhaus@futureapps.de> wrote:

>> Which definition is that?
> 
> Conflict of interest.  For both interests to coexist, there must be a
> compromise.  In this case, software quality is compromised.  So to
> recap, it is favorable to have no conflict of interest so you don't
> have to reduce quality.

If your sole goal is software quality.

But if there is not also a goal of software usability, the net effect
of the software may be zero.

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> I definitely agree with "paid." The rest is easy who pays, how and for
> what. (:-))

For writing software, for helping with writing software,
for writing compilers that let you produce software, etc.


>>I would feel much better if people understood that each of us
>>can make a living when the others can do that, too.

> a charity-driven developing rather than
> welfare-driven one. Is it better?

No, not charity.
Just a calculation by "production parties" P(i) based on these premises:

(a) work needs to be done,
(b) there exist paying customers.

Why should, for any i, P(i) be fighting to get all of (a), hence
all of (b)? If you ponder this a bit, from several points of view,
you'll see it's nonsense.

But of course, it seems our kids are taught that it makes a lot of sense
to fight everyone else off from any resource, even though this resource
will just feed you beyond 450 pounds, metaphorically speaking.
Some other tribe could hog your wild boar... 

Re: Making money on open source, if not by selling _support_, then how?

[Martin Dowie]

Randy Brukardt wrote:
> It's this argument that tars "open source" with the "communist" label (since
> that is the only way to decouple means of support from the act of creating
> software). And, in any case, it's unrealistic. I don't see any intrinsic
> reason that "open source" has to be incompatible with capitalism, but it's
> quite important that the creators get some of the rewards. In the current
> world, it is the leeches of the world (marketers, lawyers, etc.) that get
> most of the money; the creators get little of it.

This argument is so true, that I ended up marrying a Chartered Marketer! :-)

-- Martin

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Wed, 12 Apr 2006 19:11:34 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>> I definitely agree with "paid." The rest is easy who pays, how and for
>> what. (:-))
> 
> For writing software, for helping with writing software,
> for writing compilers that let you produce software, etc.

... and *quality* is as always lost somewhere between the lines.

>>>I would feel much better if people understood that each of us
>>>can make a living when the others can do that, too.
> 
>> a charity-driven developing rather than
>> welfare-driven one. Is it better?
> 
> No, not charity.
> Just a calculation by "production parties" P(i) based on these premises:
> 
> (a) work needs to be done,
> (b) there exist paying customers.
> 
> Why should, for any i, P(i) be fighting to get all of (a), hence
> all of (b)? If you ponder this a bit, from several points of view,
> you'll see it's nonsense.

The problem with the above is that neither of the components of this nice
formula is directly measurable, or stable. Otherwise, planned economy would
be possible, and also, be much more attractive than yours, because of its
physical rather spiritual way of acting.

> But of course, it seems our kids are taught that it makes a lot of sense
> to fight everyone else off from any resource, even though this resource
> will just feed you beyond 450 pounds, metaphorically speaking.
> Some other tribe could hog your wild boar...

That is exactly a communist way of perception. No offense meant. You want
to change people to make them fit to your ideals. It is inhumane, at least.
(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Randy Brukardt]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:nT7%f.4699$7Z6.366@trnddc06...
...
> > Which means no creations at all.
>
> You can't conclude that.  If that were a true statement, we would not
> have the rich library of GNU software that exists today.  Why?
> Because there's nothing to stop a GNU developer from having a day job.
> I suspect most self supporting GNU developers have day jobs.

But that's my point. Taken to it's limit, there could be no well-paying "day
jobs" for those GNU developers. After all, most of them are employed at
companies that get some benefit from the GNU software. In the limit, where
software was worth $0, there would be no "day jobs" in fields that are even
remotely related.

If the day job is unrelated (or even only weakly related), then the
developers are either not developing great software, or are short-changing
someone (their employers, their families, themselves, etc.) Great software
requires at least some of the developers putting a large amount of mental
energy into the design and the vision (and keeping to that design and
vision). That's incompatible with a "day job" that requires significant
mental energy, which is the vast majority of them. (I suppose you could work
at a Wal-Mart-like job, if you don't mind living below the poverty line. But
I happen to think software is too important to the world for developers to
be forced to live at poverty levels...). You can cheat your employer, of
course, but that's not a recipe for a sustanable model. Nor is "work,
program, sleep" a model for healthy living.

In any case, most GNU software is a long ways from being great. Being better
(arguably) than other software out there is not the same as being great.

                                         Randy.

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

On Wed, 2006-04-12 at 21:37 +0200, Dmitry A. Kazakov wrote:

> > (a) work needs to be done,
> > (b) there exist paying customers.
> > 
> > Why should, for any i, P(i) be fighting to get all of (a), hence
> > all of (b)? If you ponder this a bit, from several points of view,
> > you'll see it's nonsense.
> 
> The problem with the above is that neither of the components of this nice
> formula is directly measurable,

Need is measurable: Someone seeing a carpenter saying, "I need
a cupboard" is certainly measurable. Paying customers are
measurable, too, count them, and sum the paid bills.

>  or stable.

Who said business could be stable? That would be beyond silly.
And not just because a start-up can, by starting _up_, not
be stable.
Thing is, we can observe how people of one group make
others' lives more difficult than do people in some other group,
by trying to cheat, playing tricks, etc.. Things that would
cause major reprimands in a family situation, and things that
otherwise would make prosecutors have a look.

The software market is screwed up in many ways. Far from being
ideological, I think it is fair, for example, to assume that companies
developing MS digital video software of any kind will have to pay next
to nothing to Microsoft ... now. They may even get subsidies from MS.
Now we are taught to consider the following clever:

- fall for the MS offer now, if you think can get into some
  market.
- MS making this offer, effectively pushing the competition into
  oblivion.

Is this a rational setting? Will we win or loose, on he whole?
Answer: The company that comes out rich has always been: Microsoft.
Conclusion?

Any long term rational actor in an economy would have to say, not
clever in the first case. But most will fall for it,
see Mancur Olson's analysis, for example.


>  Otherwise, planned economy would
> be possible, and also, be much more attractive than yours, because of its
> physical rather spiritual way of acting.

If someone starts some method of financially rewarding software
production, and it works, and you say, huh, this is XYZism, than
your priestly remark adds the ideology, not the working business
model.

There is no relation of software ERP to some vastly undefined fantasy
that is commonly called planned economy. There is no
unplanned, spontaneous economy either: economy depends on
what the participants do. They make plans (which can fail),
and they act spontaneously. The question is, how, and guided
by what? No need to look at this starting from alleged ideals,
or ideologies. A mojor GPL software business has surprised us
with having some $350 Mio to buy JBoss. Planned or not?


> That is exactly a communist way of perception.

Not mine, though.

>  No offense meant. You want
> to change people to make them fit to your ideals. It is inhumane, at least.
> (:-))

I certainly do not want to change people, let me just remind you
that people choose. And certainly I can change the amount of
information that is available.

Ask people about the features and misfeatures of Ada.
What is a good way to change the perception of Ada?

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-12, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>>> 1. Rewarding true inventors (rather than monopolists, publishers,
>>> investors, lobbyists etc.)
>> 
>> There are intrinsic rewards with creating GNU software.  When you say
>> "rewarding" here, are you talking purely in terms of remuneration
>> (that is, extrinsic rewards)?
>
> Both. See Randy's answer.

My comment stands.  There are enough rewards for open source
development to continue - so there is no need to introduce more
rewards.  The lack of extrinsic rewards are not a problem, because
there is enough motivation for open source development without it.
Even when extrinsic rewards become necessary to motivate development
for a particular product, offering compensation directly to a
developer does not require leaving the open source model.

> [...]
>> Copyright has recently turned into something that actually *reduces*
>> the distribution of creative works to the public.
>
> Yes, and it only supports the point. The copyright and patent
> systems do not reward inventors. They do publishers.

Absolutely.  It supports the anti-copyright /part/ of your point.
This is why the closed source cathedral approach fails.  

CopyLEFT on the other hand opens distribution to the public - so this
is where open source succeeds in getting creative works to the
consumer.  If I understand you, you're claiming that the lack of
rewards is a "problem" for both models, but you've failed to show this
for open source.

>> Yet GNU software exists, so where's the problem?
>
> The problem is in the word "yet." GNU is a protest movement, protest
> against the existing [bad] system, by people who have money earned
> elsewhere. I don't see how this can solve the problem.

It solves the problem of getting the tools to the consumers.  It
solves this problem very well, particularly because unsatisfied
consumers are further empowered serve themselves by modifying the
product as needed.

Trying to encourage extrinsic motivators is a solution lacking a
problem.  GNU creators are already motivated.  This software has been
growing for over twenty years now, so it's well beyond any kind of
temporary "protest."

> Is it the idea that the flight-control software should be developed
> by welfare recipients? The crux is funding. Funding from support is
> inherently corrupt, I agree with Randy.

Flight control software is an excellent example of something that
should be open source; particularly because it would not require
volunteers.  The federal government (a likely consumer who is
prohibited from copyright) could hire contractors to produce flight
control software under a contract that prohibits the contractors from
copyrighting it.

>> Moreover, if quality software is the goal, the traditional model is
>> inadequite.  The contemporary copyleft GNU type model is better
>> suited for this.  To illustrate, you can figure that Microsoft
>> products were strictly produced under Bill Gates cathedral (closed)
>> software model.  Now compare the quality of those products to the
>> quality of GNU tools.  Need I say more here?
>
> Scientific questions aren't decided by voting. Everything depends on
> who is the priest in the cathedral. It can easily turn to an orgy.

Right, so not everyone will understand that comparison.  Some may see
the evidence immediately by comparing the products of the two
approaches, while others might look at the motivating forces, like the
freedom to produce good works in the open source community versus the
restrictions that prevent closed source products from achieving
quality, particularly (but not limited to) the bottom line.

>>> 2. Selecting targets of public interest (70% of software isn't
>>> needed independently on its quality.)
>> 
>> What do you mean by this?
>
> The system feeds itself. Go to any software store and ask yourself,
> if all these products were for free, would you take time to install
> them. With the software written on customer demand, it is even
> worse. It is probably 80% of software which is not needed, and even
> damaging to customer's core business.

Sure, this is an issue with closed source, where you must take the
whole black box in one piece.  You might not want IE, but if you need
Windows, too bad.  Again, the open source model solves this by
enabling the user to be as selective as they are technically able to,
from keeping tools small, and right down to trashing code fragments
and recompiling.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-12, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> In article <RI7%f.4698$7Z6.3710@trnddc06>, Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>> 
>> Conflict of interest.  For both interests to coexist, there must be
>> a compromise.  In this case, software quality is compromised.  So
>> to recap, it is favorable to have no conflict of interest so you
>> don't have to reduce quality.
>
> If your sole goal is software quality.

Right, I was purely addressing the matter of quality there; nothing
more.

> But if there is not also a goal of software usability, the net
> effect of the software may be zero.

In terms of usability, open source software is clearly more usable
because you're free to modify it, aggregate different pieces,
redistribute..  The idea actually emerged because Stallman was
aggravated with unusable black box software that he was constantly
forced to make use of.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Jean-Pierre Rosen]

I can't resist dropping in and mentionning the model of AdaControl:

A company (in this case Eurocontrol) pays for the initial development, 
and releases the software as free software. Then other companies pay for 
improvements. In the end, every interested company paid for only a 
fraction of the whole development cost, and everybody benefits of the 
whole product.

See my paper in the December 2005 issue of the Ada User Journal for details.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Thu, 13 Apr 2006 02:58:50 GMT, Justin Gombos wrote:

> My comment stands.  There are enough rewards for open source
> development to continue - so there is no need to introduce more
> rewards.  The lack of extrinsic rewards are not a problem, because
> there is enough motivation for open source development without it.

So, if everything is fine, then why quality is so poor?

>>> Copyright has recently turned into something that actually *reduces*
>>> the distribution of creative works to the public.
>>
>> Yes, and it only supports the point. The copyright and patent
>> systems do not reward inventors. They do publishers.
> 
> Absolutely.  It supports the anti-copyright /part/ of your point.
> This is why the closed source cathedral approach fails.  
> CopyLEFT on the other hand opens distribution to the public - so this
> is where open source succeeds in getting creative works to the
> consumer.  If I understand you, you're claiming that the lack of
> rewards is a "problem" for both models, but you've failed to show this
> for open source.

No, the burden of proof / enlightenment is on your side. I don't see any
functioning mechanism of rewarding in either model.

I fully agree with "openness" as a legal right of each citizen to know what
is going on in the things directly influencing his/her life. It is no
different from ingredients list of a food product. But it isn't a major
component of quality, neither it is a way of rewarding.

>>> Yet GNU software exists, so where's the problem?
>>
>> The problem is in the word "yet." GNU is a protest movement, protest
>> against the existing [bad] system, by people who have money earned
>> elsewhere. I don't see how this can solve the problem.
> 
> It solves the problem of getting the tools to the consumers.  It
> solves this problem very well, particularly because unsatisfied
> consumers are further empowered serve themselves by modifying the
> product as needed.

This is another inherently invalid argument. A consumer, by definition, is
somebody unable or unwilling to produce the product by itself. "Unable"
here means, in particular, economically, technically, mentally, physically
etc infeasible.

>> Is it the idea that the flight-control software should be developed
>> by welfare recipients? The crux is funding. Funding from support is
>> inherently corrupt, I agree with Randy.
> 
> Flight control software is an excellent example of something that
> should be open source; particularly because it would not require
> volunteers.  The federal government (a likely consumer who is
> prohibited from copyright) could hire contractors to produce flight
> control software under a contract that prohibits the contractors from
> copyrighting it.

I.e. as soon as we take a thing where mission is critical (=quality is
paramount), you give up and let the government to intervene. This presumes
a better motivation of programmers, than ones operating at the bazar. Why
so little trust in customers? I vividly imagine how family members of those
who suffered in the most recent plane crash, would turn their computers on
and start to patch the software. It is an excellent motivation too, want to
return from next day trip? - join our Brake Control System Initiative!

>> The system feeds itself. Go to any software store and ask yourself,
>> if all these products were for free, would you take time to install
>> them. With the software written on customer demand, it is even
>> worse. It is probably 80% of software which is not needed, and even
>> damaging to customer's core business.
> 
> Sure, this is an issue with closed source, where you must take the
> whole black box in one piece.  You might not want IE, but if you need
> Windows, too bad.  Again, the open source model solves this by
> enabling the user to be as selective as they are technically able to,
> from keeping tools small, and right down to trashing code fragments
> and recompiling.

No, I don't want to do the integration work by myself. I am a customer. I
want to do only my job. This is independent on openness. Example: Linux
distributions.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Wed, 12 Apr 2006 23:56:19 +0200, Georg Bauhaus wrote:

> On Wed, 2006-04-12 at 21:37 +0200, Dmitry A. Kazakov wrote:
> 
>>> (a) work needs to be done,
>>> (b) there exist paying customers.
>>> 
>>> Why should, for any i, P(i) be fighting to get all of (a), hence
>>> all of (b)? If you ponder this a bit, from several points of view,
>>> you'll see it's nonsense.
>> 
>> The problem with the above is that neither of the components of this nice
>> formula is directly measurable,
> 
> Need is measurable: Someone seeing a carpenter saying, "I need
> a cupboard" is certainly measurable.

It is not the data one needs to open a furniture store. Economy does not
function this way. 

> Paying customers are
> measurable, too, count them, and sum the paid bills.

You have to get paying customers first. Note that Randy's point about
perfect software nicely fits to your example. A quality cupboard is bought
once per human life. I don't want to be an IKEA's "paying customer."  I
don't want them shipping me logs instead of furniture.

>>  or stable.
> 
> Who said business could be stable?

Not business, but the parameters you need to control production. Market
economy solves the problem uncertainty by moderate wasting the resources.
It follows all adjacent paths. It is a sort of breadth-first search. This
is not a universal solution though, especially when resources are limited.
We can observe that in the software developing sector, market produces
immense wasting without quality.

>> Otherwise, planned economy would
>> be possible, and also, be much more attractive than yours, because of its
>> physical rather spiritual way of acting.
> 
> If someone starts some method of financially rewarding software
> production, and it works, and you say, huh, this is XYZism, than
> your priestly remark adds the ideology, not the working business
> model.

I just don't believe in any model based on ideological or religious
imperative.

> Ask people about the features and misfeatures of Ada.
> What is a good way to change the perception of Ada?

There is no good way, because Ada is a committee language (which is
*good*), a relic of the epoch, when quality was an issue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Marc A. Criley]

Jean-Pierre Rosen wrote:
> I can't resist dropping in and mentionning the model of AdaControl:
> 
> A company (in this case Eurocontrol) pays for the initial development, 
> and releases the software as free software. Then other companies pay for 
> improvements. In the end, every interested company paid for only a 
> fraction of the whole development cost, and everybody benefits of the 
> whole product.

And this occurs in the proprietary software world as well.  On two 
instances in my career a customer pays a vendor to modify their product 
in a certain way.  The vendor continues to own the product in whole, the 
customer simply now gets a release that does what they need--and all the 
vendor's other customers get that improved product as well.

(My involvement was with unrelated vendor/customer pairs, once on the 
customer side, and once on the vendor side, and so I'm sure this is not 
an uncommon occurrence.)

-- Marc A. Criley
-- McKae Technologies
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Thu, 13 Apr 2006 08:18:36 -0500, Marc A. Criley wrote:

> And this occurs in the proprietary software world as well.  On two 
> instances in my career a customer pays a vendor to modify their product 
> in a certain way.  The vendor continues to own the product in whole, the 
> customer simply now gets a release that does what they need--and all the 
> vendor's other customers get that improved product as well.
>
> (My involvement was with unrelated vendor/customer pairs, once on the 
> customer side, and once on the vendor side, and so I'm sure this is not 
> an uncommon occurrence.)

Yes, it happens. I also witnessed such cases. But usually it does when the
customer is relatively distant to software business. They might require
that the product won't be licensed to competitors. Though, normally
customers feel that if they have paid for developing, they also should own
the result of.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then

[Larry Kilgallen]

In article <739b0$443e4f69$45491254$22018@KNOLOGY.NET>, "Marc A. Criley" <mcNOSPAM@mckae.com> writes:

> And this occurs in the proprietary software world as well.  On two 
> instances in my career a customer pays a vendor to modify their product 
> in a certain way.  The vendor continues to own the product in whole, the 
> customer simply now gets a release that does what they need--

and gets assurance that the modifications will continue in the product
line.  This is a major improvement to the mainframe model where customers
get source to the product but will have to re-integrate local changes
into successive versions of the product.

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

>> Need is measurable: Someone seeing a carpenter saying, "I need
>> a cupboard" is certainly measurable.
> 
> It is not the data one needs to open a furniture store.

I think that all of todays furniture stores are mostly in
the hands of heirs. So lets not discuss furniture, but software.
I said that, on the whole, there is no point in Producer(i)
trying to hog all potential orders in a market, if you ponder
this a bit.

In fact, many western economies do have rules that should avoid
the effect of P(i).gets(every order) for just one i. It's just
that Microsoft manages to circumvent the application of the
rules.


> Economy does not
> function this way. 

Well who said economy functions this or that way? (I've made a
claim that many people in the software market behave in certain
ways, and that this has certain effects. No "economy" in sight.)
In fact, no one knows anything about how economy works, really.
Although certainly personal acquaintance with those who can
open doors is a crucial factor in most kinds of business.


>> Paying customers are
>> measurable, too, count them, and sum the paid bills.
> 
> You have to get paying customers first.

Do I?


> I just don't believe in any model based on ideological or religious
> imperative.

Then let's drop your ideology contribution from the
discussion, o.K.?


>> Ask people about the features and misfeatures of Ada.
>> What is a good way to change the perception of Ada?

> There is no good way, because Ada is a committee language (which is
> *good*), a relic of the epoch, when quality was an issue.


It is certainly an advantage if you have something to say about
Ada to potential customers who ask you about Ada.
For example,
"we have had to write some concurrent code doing such and such.
It turned out Ada's concurrency features worked nicely.
The implementation is correct, efficient, and we had it finished
almost in time."

Can you say that about Ada?

Re: Making money on open source, if not by selling _support_, then

[Justin Gombos]

On 2006-04-13, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> In article <739b0$443e4f69$45491254$22018@KNOLOGY.NET>, "Marc A. Criley" <mcNOSPAM@mckae.com> writes:
>
>> And this occurs in the proprietary software world as well.  On two
>> instances in my career a customer pays a vendor to modify their
>> product in a certain way.  The vendor continues to own the product
>> in whole, the customer simply now gets a release that does what
>> they need--
>
> and gets assurance that the modifications will continue in the
> product line.  This is a major improvement to the mainframe model
> where customers get source to the product but will have to
> re-integrate local changes into successive versions of the product.

You get no such assurance with closed proprietary software because you
are at the mercy of the vendor to provide this (and remain in
business).  This risk evaporates when you're working with open source,
as there is always the option of hiring a contractor (which has the
added benefit of keeping the cost a competitive market rate rather
than a monopolizing inflated rate).

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then

[Larry Kilgallen]

In article <SLx%f.11892$Q92.6911@trnddc04>, Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
> On 2006-04-13, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
>> In article <739b0$443e4f69$45491254$22018@KNOLOGY.NET>, "Marc A. Criley" <mcNOSPAM@mckae.com> writes:
>>
>>> And this occurs in the proprietary software world as well.  On two
>>> instances in my career a customer pays a vendor to modify their
>>> product in a certain way.  The vendor continues to own the product
>>> in whole, the customer simply now gets a release that does what
>>> they need--
>>
>> and gets assurance that the modifications will continue in the
>> product line.  This is a major improvement to the mainframe model
>> where customers get source to the product but will have to
>> re-integrate local changes into successive versions of the product.
> 
> You get no such assurance with closed proprietary software because you
> are at the mercy of the vendor to provide this (and remain in
> business).

If you don't have that assurance, then you did a bad job of reviewing
the contract you signed.

If the vendor issues no more versions, then you still have the guarantee
I cited (vendor not issueing incompatible versions).

Re: Making money on open source, if not by selling _support_, then

[Justin Gombos]

On 2006-04-13, Larry Kilgallen <Kilgallen@SpamCop.net> wrote:
> In article <SLx%f.11892$Q92.6911@trnddc04>, Justin Gombos <rpbkbq.xax.gld@uluv.kbq> writes:
>
> If you don't have that assurance, then you did a bad job of
> reviewing the contract you signed.

Sure, with the closed source route, your degree of support reassurance
is limited by the quality of the contract.  Moreover, even the best of
contracts cannot guarantee the vendor remains in business.  If they
close, your only hope is that they turn over the source code (assuming
your contract had this foresight).  Yet still, they ultimately don't
have to comply with the contract in the end, as the actual
consequences of non-compliance might be preferred.

I've been involved in cases where a support contract was violated.  We
were careful to inject a price control, so the vendor could not
excessively jack up the price of support down the line.  They did so
anyway, because they had no choice.  If they did not overcharge, they
would have lost money due to unforeseen expenses on their end.  We
could have sued, and perhaps drive them out of business, but we were
dealing with diminishing returns at this point.

Had the product been open source, we would have had the option of
simply switching to a better competitor.  It's more favorable to have
natural guarantees than to depend on folks following some artifical
rules (since contractual compliance is optional in a strict sense).
If things go poorly, and you're fortunate enough to be on the right
side of the contract, you're still dependant on favorable litigation
results.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Thu, 13 Apr 2006 16:18:35 +0200, Georg Bauhaus wrote:

> Dmitry A. Kazakov wrote:
> 
>>> Need is measurable: Someone seeing a carpenter saying, "I need
>>> a cupboard" is certainly measurable.
>> 
>> It is not the data one needs to open a furniture store.
> 
> I think that all of todays furniture stores are mostly in
> the hands of heirs. So lets not discuss furniture, but software.
> I said that, on the whole, there is no point in Producer(i)
> trying to hog all potential orders in a market, if you ponder
> this a bit.
> 
> In fact, many western economies do have rules that should avoid
> the effect of P(i).gets(every order) for just one i. It's just
> that Microsoft manages to circumvent the application of the
> rules.

The point stands. You cannot measure it. MS is able to circumvent whatever
the rules exactly for this reason. If that were measurable, there would be
no need to enforce them in courts. You need no court to decide whether the
bulb will light up. It is 230V. Turn the switch on and it does.

[ Instead of idiotic requirements to separate MediaPlayer from Windows, the
government should pass laws enforcing liability of commercial software
vendors. ]

>> Economy does not
>> function this way. 
> 
> Well who said economy functions this or that way?

Nobody. I said it does *not*! (:-))

> (I've made a
> claim that many people in the software market behave in certain
> ways, and that this has certain effects. No "economy" in sight.)
> In fact, no one knows anything about how economy works, really.
> Although certainly personal acquaintance with those who can
> open doors is a crucial factor in most kinds of business.

You have stated some imperative rules. My point was that these rules
obviously are not ones by which economical agents act. So you have to
translate these rules into ones of the market economy and try to define a
framework which would be in favor of them. In the end it means adjusting
the economical system. The scale of adjustment needed is up to you. An
alternative is to have agents which do not obey market, but take
*ideological* decisions. These could be the government, GNU movement,
Church, Politburo etc. 

>>> Paying customers are
>>> measurable, too, count them, and sum the paid bills.
>> 
>> You have to get paying customers first.
> 
> Do I?

Sure, how could you measure non-existent customers?

>>> Ask people about the features and misfeatures of Ada.
>>> What is a good way to change the perception of Ada?
> 
>> There is no good way, because Ada is a committee language (which is
>> *good*), a relic of the epoch, when quality was an issue.
> 
> It is certainly an advantage if you have something to say about
> Ada to potential customers who ask you about Ada.
> For example,
> "we have had to write some concurrent code doing such and such.
> It turned out Ada's concurrency features worked nicely.
> The implementation is correct, efficient, and we had it finished
> almost in time."
> 
> Can you say that about Ada?

No. It does not come to this. At least in talks with the customers I
contacted with. They don't use words like "concurrency."

If you rather meant software developers, then they firstly do not take
decisions about the language to be used, and, secondly, they on the whole
are very reluctant when it comes to language or paradigm switch. It was
different 20 years ago, when people tried to know and try everything about
computers. Today, it is physically impossible. Then there are too many
programmers to keep education standard high. So the culture of programmers
has adapted to the new situation.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

On Fri, 2006-04-14 at 12:01 +0200, Dmitry A. Kazakov wrote:

> > In fact, many western economies do have rules that should avoid
> > the effect of P(i).gets(every order) for just one i. It's just
> > that Microsoft manages to circumvent the application of the
> > rules.
> 
> The point stands. You cannot measure it.

People *do* measure the number of orders from Producer(i).
Of course they do, how could the AT&T case, the IBM case,
and even the MS cases fail to recognize these quantities?

Or do you imagine some notion of so-called precise measurements
of an artificially defined set of physically continuous qualities?
No one has ever measured the friction of wind and windshield
exactly. That kind of exactitude still is a useful technical
term. (I bet the rocket scientists in this forum will have a
lot to say about the role of approximation in friction
measurements, and calculations.)

Obviously, different technical terms apply in law, or economy,
hence different measures are applied, and used for making
decisions.

>  MS is able to circumvent whatever
> the rules exactly for this reason. If that were measurable, there would be
> no need to enforce them in courts.

In this sense, nothing whatsoever is measurable.
That's just a scientific fiction that happens to be
working well.
However, "Don't kill" is a rule of civil law that is fairly easily
measured, and is enforced in courts. (And or measuring, see
"12 Angry Men" :)

A light bulb can be turned on by 100V, too, and you can try
245V as well. Depending on how dim the light is, some people
will say (measure), it is on, others will say it is off.
With the exception of trivial truths like atom bomb exploded
or not, there is no absolute, scientific measure of anything.


> [ Instead of idiotic requirements to separate MediaPlayer from Windows, the
> government should pass laws enforcing liability of commercial software
> vendors. ]


> You have stated some imperative rules.

Where have I stated imperative rules?

>  An
> alternative is to have agents which do not obey market,

There is no market to obey, there are only exchanges of money
and goods, and law, and informal rules. If some "theorists" use
these phenomena to construct a notion of "market", that's their
business.
Which one do you have in mind?

> >>> Paying customers are
> >>> measurable, too, count them, and sum the paid bills.
> >> 
> >> You have to get paying customers first.
> > 
> > Do I?
> 
> Sure, how could you measure non-existent customers?

If a bank considers whether or not you are eligible for a money
loan for a new software business, they want to see you present
a business plan (all of: you, the business plan, and you presenting
the business plan).
Customers are not something that you can measure by exactly counting
them when all that is known is the prospective future. It's called
speculation, and risk management.


> > It is certainly an advantage if you have something to say about
> > Ada [...]

> > Can you say that about Ada?
> 
> No. It does not come to this.

It will come to this the moment you drop a few words about Ada,
with caution.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Fri, 14 Apr 2006 14:55:39 +0200, Georg Bauhaus wrote:

> On Fri, 2006-04-14 at 12:01 +0200, Dmitry A. Kazakov wrote:
> 
>>> In fact, many western economies do have rules that should avoid
>>> the effect of P(i).gets(every order) for just one i. It's just
>>> that Microsoft manages to circumvent the application of the
>>> rules.
>> 
>> The point stands. You cannot measure it.
> 
> People *do* measure the number of orders from Producer(i).
> Of course they do, how could the AT&T case, the IBM case,
> and even the MS cases fail to recognize these quantities?
> 
> Or do you imagine some notion of so-called precise measurements
> of an artificially defined set of physically continuous qualities?
> No one has ever measured the friction of wind and windshield
> exactly. That kind of exactitude still is a useful technical
> term. (I bet the rocket scientists in this forum will have a
> lot to say about the role of approximation in friction
> measurements, and calculations.)
>
> Obviously, different technical terms apply in law, or economy,
> hence different measures are applied, and used for making
> decisions.

The measure should have accuracy suitable for prediction / control.
Immeasurable <= not enough accurate.

>>  MS is able to circumvent whatever
>> the rules exactly for this reason. If that were measurable, there would be
>> no need to enforce them in courts.
> 
> In this sense, nothing whatsoever is measurable.
> That's just a scientific fiction that happens to be
> working well.
> However, "Don't kill" is a rule of civil law that is fairly easily
> measured, and is enforced in courts. (And or measuring, see
> "12 Angry Men" :)

"Clinical/brain death" and "one caused by suspect's action" are different
"measures." Courts are busy with the later, you refer to the former. Which
by the way, is also now that simple, as the recent court drama in America
has shown.

>>  An
>> alternative is to have agents which do not obey market,
> 
> There is no market to obey, there are only exchanges of money
> and goods, and law, and informal rules. If some "theorists" use
> these phenomena to construct a notion of "market", that's their
> business.

It is a deep philosophical question unrelated to the discussion. You can
consider market (and all others) laws as really existing objects or as
imaginary ones. It is irrelevant.

>>> Can you say that about Ada?
>> 
>> No. It does not come to this.
> 
> It will come to this the moment you drop a few words about Ada,
> with caution.

No runner. You have missed the starting point: technical superiority does
not matter. So you cannot have any reasonable platform to discuss merits of
Ada with customers. It would be different if they saw it in commercials.
But they don't. Neither it is necessary. Ideally, customer should delegate
this to the contractor.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

Dmitry A. Kazakov wrote:

> The measure should have accuracy suitable for prediction / control.

Well, yes, typical economical measurements are used for
politically important predictions. This is a fact.

> Immeasurable <= not enough accurate.

Yes, and accuracy is a thing that is defined by people.
It isn't 100% induced into some ontology by the the thing to
be measured.


> "Clinical/brain death" and "one caused by suspect's action" are different
> "measures."

Different grain size, same scale label. The formal words
"discretion" and "judgement" even have the word "measurement"
in them, in German: Er-messen. For a reason.

>> there are only exchanges of money
>> and goods, and law, and informal rules.

> It is a deep philosophical question unrelated to the discussion.

No, when it comes to decision making, observations and perceptions
are just facts:
People do measure the quality of programs, even though they do not
always state their criteria. People do discuss the relative value
of programming languages, even though other people might consider
more or less criteria, and say some are missing from the evaluation.

>>>> Can you say that about Ada?
>>> No. It does not come to this.
>> It will come to this the moment you drop a few words about Ada,
>> with caution.
> 
> No runner. You have missed the starting point: technical superiority does
> not matter.

I'm not asking you to say "better" or "worse" than, in technical
terms. I'm not asking you to brag about technical superior
Ada programs. I'm asking you to cautiously mention Ada, because
when people start connecting this kind of program with this "Ada-word",
they form an opinion.

This can be a reasonable approach to inform, fleetingly, about the
merits of Ada: by not stressing its merit. Just make sure it gets
connected to the desirable qualities of software products.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-12, Georg Bauhaus <bauhaus@futureapps.de> wrote:
> Justin Gombos wrote:
>
> Conflicting interests can also bring software production back on
> track. How about this: Sometimes programmers go astray and enjoy
> themselves writing wonderfully sophisticated "high quality"
> Ada. Meanwhile the toaster company goes out of business because
> their embedded temperature sensors will be so great, when they will
> finally arrive...

Right, so high quality products can have side effects, one of which is
lengthy development time.  This doesn't diminish the quality, but
rather the viability for the toaster company to leverage business gain
from whatever open source project they've targeted.

Your example requires you to combine two different open source models.
If the toaster company funds the development, then their interests are
in the forefront of the project, enabling them to control both the
quality and direction of the project.  If the toaster company is not
funding the effort, then they have no expectation of what direction
the product will take.  In this case, the problem is not with the open
source project they're trying to use, but rather the toaster company's
inability to plan ahead and select the right tool for the job (and
insource what they need if their supplier can't deliver what they
need, when they need it).

> How could we possibly know which interest are the ones that make us
> write the really great software products? What exactly is the one
> interest in the set of conflicting interests that should dominate
> because no compromise can be better?

In terms of pure quality, interests that favor quality should dominate
opposing interests, obviously.  One way or another, profits and rapid
production are often the competing interest that reduces quality.  If
you're focused on the bottom line, you must limit quality to that of
the requirement; you would be a poor businessman if you didn't.
Because the open source paradigm (particularly the non-profit variety)
is largely free from these conflicts, it naturally acquires the
charactoristics inherent in producing great products.

> Maybe there is not so much a compromising compromise but rather a
> method of combining the various interests into a satisfying solution
> to a problem. Presuming a problem is well defined, ever, in the real
> world.

Sure, a /satisfying/ solution (with satisfactory product quality) has
more tolerance for accommodating other interests, such as rapid
development and profit margin.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-12, Randy Brukardt <randy@rrsoftware.com> wrote:
> "Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
> news:nT7%f.4699$7Z6.366@trnddc06...
> ...
>> > Which means no creations at all.
>>
>> You can't conclude that.  If that were a true statement, we would
>> not have the rich library of GNU software that exists today.  Why?
>> Because there's nothing to stop a GNU developer from having a day
>> job.  I suspect most self supporting GNU developers have day jobs.
>
> But that's my point. Taken to it's limit, there could be no
> well-paying "day jobs" for those GNU developers. After all, most of
> them are employed at companies that get some benefit from the GNU
> software. In the limit, where software was worth $0, there would be
> no "day jobs" in fields that are even remotely related.

How could there be no day job available for GNU developers?  Whatever
your answer, it must be purely hypothetical, because GNU developers
*do* have day jobs.  If they didn't, you'd have to explain how all the
GNU developers have been surviving for the past 20+ years.  And what
prevents such day jobs from being well paying?

> If the day job is unrelated (or even only weakly related), then the
> developers are either not developing great software, or are
> short-changing someone (their employers, their families, themselves,
> etc.) Great software requires at least some of the developers
> putting a large amount of mental energy into the design and the
> vision (and keeping to that design and vision). That's incompatible
> with a "day job" that requires significant mental energy, which is
> the vast majority of them. 

It seems you're making a lot of assumptions here, which in the end
probably boils down to a very small group.  You're assuming a Henry
Ford 40 hour work week, or greater.  You're assuming these are
mentally exhausting day jobs, and you're assuming that the subject is
easily fatigable.  You're also assuming that the mental energy
required at work is the same type of mental energy that the subject
would use in their GNU development (a lot of commercial software
effort involves what I call metawork - administrative overhead and
meetings talking about the work itself).

Someone who is burned out working 70+ hour weeks on their day job
doing the same work that GNU development involves is not suitable for
writing quality GNU code; and such folks are unlikely to pursue GNU
development.  Seeing that offtime volunteer GNU work is done for
leisure, you can figure that those who do it aren't burned out to the
point of being careless about quality.  Why?  Because intrinsic
motivators are at work.

> (I suppose you could work at a Wal-Mart-like job, if you don't mind
> living below the poverty line. But I happen to think software is too
> important to the world for developers to be forced to live at
> poverty levels...).

So what?  If someone chooses manual labor during the day, and mental
labor in their off hours, fine.  

The lifestyle of a GNU developer is chosen, not forced.

> You can cheat your employer, of course, but that's not a recipe for
> a sustanable model. Nor is "work, program, sleep" a model for
> healthy living.

Healthy living is a different issue entirely.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-13, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Thu, 13 Apr 2006 02:58:50 GMT, Justin Gombos wrote:
>> 
>> Absolutely.  It supports the anti-copyright /part/ of your point.
>> This is why the closed source cathedral approach fails.  CopyLEFT
>> on the other hand opens distribution to the public - so this is
>> where open source succeeds in getting creative works to the
>> consumer.  If I understand you, you're claiming that the lack of
>> rewards is a "problem" for both models, but you've failed to show
>> this for open source.
>
> No, the burden of proof / enlightenment is on your side. I don't see
> any functioning mechanism of rewarding in either model.

To see it, you only need to observe the fact that open source software
exists, and continues to grow.  From this observation alone, you know
that there is a mechanism of rewards to promote such development.

> I fully agree with "openness" as a legal right of each citizen to
> know what is going on in the things directly influencing his/her
> life. It is no different from ingredients list of a food
> product. But it isn't a major component of quality, neither it is a
> way of rewarding.

The openness of the code *is* one of many components of quality.
Besides the quality built into the process of open source development,
you also have the benefit of potentially millions of eyes looking at
the product and discovering defects in the code.

And with respect to "ways of rewarding," this still remains a solution
looking for a problem.  Regardless of what's in place, /additional/
rewards are unnecessary; this is easily verifiable by observing growth
rate of publically available open source software.

>> It solves the problem of getting the tools to the consumers.  It
>> solves this problem very well, particularly because unsatisfied
>> consumers are further empowered serve themselves by modifying the
>> product as needed.
>
> This is another inherently invalid argument. A consumer, by
> definition, is somebody unable or unwilling to produce the product
> by itself. "Unable" here means, in particular, economically,
> technically, mentally, physically etc infeasible.

That's a rather strange definition for "consumer."  My argument is
well grounded because GNU consumers have relatively unrestricted
access to the works.  If the consumer (by your odd definition) is not
economically able to acquire the software they need, or the equipment
needed to run the software, they would not be getting any closed
source software either.

But even with your handicapped consumer, such consumers still have
much greater access to open source software, primarily because it's
free of cost, enabling widespread unrestrained distribution of
software.  The fact that they have the option of modifying it is an
extra benefit (whether they do the mods themselves or hire a
contractor) - and you can neglect those cases when talking about a
consumer handicapped in the way that you describe, and still see that
the work gets widely distributed (rather than locked up and released
for a price).

>> Flight control software is an excellent example of something that
>> should be open source; particularly because it would not require
>> volunteers.  The federal government (a likely consumer who is
>> prohibited from copyright) could hire contractors to produce flight
>> control software under a contract that prohibits the contractors
>> from copyrighting it.
>
> I.e. as soon as we take a thing where mission is critical (=quality
> is paramount), you give up and let the government to intervene. This
> presumes a better motivation of programmers, than ones operating at
> the bazar.

The client (the feds in this case) hires who they want, and will
likely hire only qualified applicants.

>> Sure, this is an issue with closed source, where you must take the
>> whole black box in one piece.  You might not want IE, but if you
>> need Windows, too bad.  Again, the open source model solves this by
>> enabling the user to be as selective as they are technically able
>> to, from keeping tools small, and right down to trashing code
>> fragments and recompiling.
>
> No, I don't want to do the integration work by myself. I am a
> customer. I want to do only my job. This is independent on
> openness. Example: Linux distributions.

Linux distributions is an excellent example here.  If you want all the
tools rolled into one distro, you simply select the distro you need.
If none exists to meet your need, and you don't want the integration
effort of rolling your own, you have the option of hiring a contractor
to do the dirty work for you.

Again, these options are largely non-existent if not greatly limited
in the closed source paradigm.  You're at the mercy of the vendor to
offer a modified product - and when they do, you better have deep
pockets because there is no one to compete against them to offer mods
on their product.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Sat, 15 Apr 2006 21:17:46 GMT, Justin Gombos wrote:

> On 2006-04-13, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Thu, 13 Apr 2006 02:58:50 GMT, Justin Gombos wrote:
>>> 
>>> Absolutely.  It supports the anti-copyright /part/ of your point.
>>> This is why the closed source cathedral approach fails.  CopyLEFT
>>> on the other hand opens distribution to the public - so this is
>>> where open source succeeds in getting creative works to the
>>> consumer.  If I understand you, you're claiming that the lack of
>>> rewards is a "problem" for both models, but you've failed to show
>>> this for open source.
>>
>> No, the burden of proof / enlightenment is on your side. I don't see
>> any functioning mechanism of rewarding in either model.
> 
> To see it, you only need to observe the fact that open source software
> exists, and continues to grow.

If you open the fridge each morning and find beer there, should this
observation lead you the conclusion, that fridges brew beer?

> From this observation alone, you know
> that there is a mechanism of rewards to promote such development.

I don't know how it works. What if my brother, who loads the fridge with
beer would turn to abstinence?

> The openness of the code *is* one of many components of quality.
> Besides the quality built into the process of open source development,
> you also have the benefit of potentially millions of eyes looking at
> the product and discovering defects in the code.

This is a model of wasting human resources in first place. Secondly it
effectively puts a limit to the complexity and quality of the software.
Millions of incompetent eyes cannot replace an educated one. Any project
manager knows that each new programmer increases risk for the project to
collapse.

> And with respect to "ways of rewarding," this still remains a solution
> looking for a problem.  Regardless of what's in place, /additional/
> rewards are unnecessary; this is easily verifiable by observing growth
> rate of publically available open source software.

... which bears all signs of pop-culture, by the way. Public involvement
destroys quality and even common sense. Turn MTV on, if you want an
example. Openness /= direct democracy.

>>> It solves the problem of getting the tools to the consumers.  It
>>> solves this problem very well, particularly because unsatisfied
>>> consumers are further empowered serve themselves by modifying the
>>> product as needed.
>>
>> This is another inherently invalid argument. A consumer, by
>> definition, is somebody unable or unwilling to produce the product
>> by itself. "Unable" here means, in particular, economically,
>> technically, mentally, physically etc infeasible.
> 
> That's a rather strange definition for "consumer."  My argument is
> well grounded because GNU consumers have relatively unrestricted
> access to the works.  If the consumer (by your odd definition) is not
> economically able to acquire the software they need, or the equipment
> needed to run the software, they would not be getting any closed
> source software either.

I meant division of labor. Customer is somebody who is specialized to
produces something else. What you describe reminds me natural economy,
which was died off especially because it was unable to provide quality,
diversity, volume of products, didn't reward invention, couldn't ensure
sustainable growth.

>>> Flight control software is an excellent example of something that
>>> should be open source; particularly because it would not require
>>> volunteers.  The federal government (a likely consumer who is
>>> prohibited from copyright) could hire contractors to produce flight
>>> control software under a contract that prohibits the contractors
>>> from copyrighting it.
>>
>> I.e. as soon as we take a thing where mission is critical (=quality
>> is paramount), you give up and let the government to intervene. This
>> presumes a better motivation of programmers, than ones operating at
>> the bazar.
> 
> The client (the feds in this case) hires who they want, and will
> likely hire only qualified applicants.

Now, my these is: hiring only qualified applicants must be the rule for
*all* types of job, if we consider a quality-oriented production. When I
say that neither of existing systems works, I mean that this selection does
not happen. Firstly, there is no efficient mechanism of selection.
Secondly, there is no motivation for people to become selected. Qualified
programmers don't grow on trees. If the reward is to work 42 hours washing
dishes and 30 contributing at night to a GNU project, then I don't see why
students should spend 10+ years studying CS. They could become managers,
advocates instead.

The attitude "it is no matter how much we pay them, because they would do
the work anyway" is deeply rooted in both systems. This is why quality
suffers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

On Sun, 2006-04-16 at 12:53 +0200, Dmitry A. Kazakov wrote:
>  this is easily verifiable by observing growth
> > rate of publically available open source software.
> 
> ... which bears all signs of pop-culture, by the way. Public involvement
> destroys quality and even common sense. Turn MTV on, if you want an
> example. Openness /= direct democracy.

pop-culture /= Public involvement, and open source does
not imply absence of project rules. 
Open source software does not by itself define how a project
is run, obviously.

Observing open source projects might be a little easier than
observing closed source projects, but you don't necessarily
see programmers at work from outside, right?
 So who are we to judge every project based on its openness
of sources?


> Now, my these is: hiring only qualified applicants must be the rule for
> *all* types of job, if we consider a quality-oriented production. When I
> say that neither of existing systems works, I mean that this selection does
> not happen. Firstly, there is no efficient mechanism of selection.
> Secondly, there is no motivation for people to become selected. Qualified
> programmers don't grow on trees. If the reward is to work 42 hours washing
> dishes and 30 contributing at night to a GNU project, then I don't see why
> students should spend 10+ years studying CS. 

An interesting assessment. I think the best source of information
is to consider the programmers in place of trees, or dishes.
There are ways to find out why they do what they do. One reported reason
is dull work that isn't fun, but you get payed.


> They could become managers,
> advocates instead.

Could you elaborate a bit how they could do this, and why they
would want to do this?

> The attitude "it is no matter how much we pay them, because they would do
> the work anyway" is deeply rooted in both systems. This is why quality
> suffers.

OK, some people want to maintain the impression that their high
pay is justified. I'm not blaming them. But on which facts could we
build a hypothesis that high wages guarantee high quality?
Conversely, can you provide evidence that lower wages warrant lower
quality of software?

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-16, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
> If you open the fridge each morning and find beer there, should this
> observation lead you the conclusion, that fridges brew beer?

Good example - faulty conclusion.  You can conclude from that
observation that you have cold beer, and therefore don't need to make
any changes to the fridge to ensure that it cools the beer, or changes
to your procurement process for getting the beer.  Likewise, open
source continues to grow substantially, so you can conclude that
additional rewards are unnecessary for the growth to continue.

>> From this observation alone, you know that there is a mechanism of
>> rewards to promote such development.
>
> I don't know how it works. What if my brother, who loads the fridge
> with beer would turn to abstinence?

Remedial action would then become necessary.  So if the open source
community loses all its developers, only then will lack of rewards
become a problem (and even then it's a matter of perception).  As of
now, death of open source would be entirely hypothetical, and we're
not living in a hypothetical world.

>> The openness of the code *is* one of many components of quality.
>> Besides the quality built into the process of open source
>> development, you also have the benefit of potentially millions of
>> eyes looking at the product and discovering defects in the code.
>
> This is a model of wasting human resources in first place. 

Wasteful in what sense?  Wasteful does not describe gaining something
for nothing, it describes losing something you have and failing to
gain.  The more eyes on the code, the more opportunity to improve the
product.

> Secondly it effectively puts a limit to the complexity and quality
> of the software.  

Quite the opposit.  It's the closed source model that limits
complexity as well as quality.  You can be limited to the mental
capacity of those hired, or you can be limited to the mental capacity
of a subset of the world population, which can well exceed the size of
any one company.  

This is precisely why published encryption algorithms are accepted
more readily than closed crypto algorithms.  You cannot rely on a few
brains to find the flaws in a complex system.

> Millions of incompetent eyes cannot replace an educated one. 

Who's to say "the educated one" is not an open source developer?  And
who's to say incompetence is not in the workplace?  Incompetence
thrives in the workplace, particularly in software, where the
extrinsic rewards are high enough to motivate folks who have no
interest in software or the quality thereof.

> Any project manager knows that each new programmer increases risk
> for the project to collapse.

This does not support your claim that the number of brains is
inversely proportional to quality, because you're not accounting for
the economic factors behind the risk you describe.  The logistics are
substantailly different in the scenario of *hiring* the extra talent.
Among other differences, the value of their contribution minus the
overhead they bring must exceed what you pay them.

>> That's a rather strange definition for "consumer."  My argument is
>> well grounded because GNU consumers have relatively unrestricted
>> access to the works.  If the consumer (by your odd definition) is
>> not economically able to acquire the software they need, or the
>> equipment needed to run the software, they would not be getting any
>> closed source software either.
>
> I meant division of labor. Customer is somebody who is specialized to
> produces something else. 

Even that definition is unrealistic.  Consumers are not necessarily so
specialized that they're incapable of tailoring tools that are
initially generic to help them do their job better.  But even if they
were, open source consumers still have the option of hiring
contractors to tailor their tools.  Closed source consumers are stuck
with a black box, and must either modify the way they work to adapt to
the tool, or try to motivate the vendor to modify it for them at a
reasonable price, or hire someone to build the tool from the ground
up.  So open source consumers have all the same options that closed
source consumer have, and then some.

> Now, my these is: hiring only qualified applicants must be the rule
> for *all* types of job, if we consider a quality-oriented
> production.

Not necessarily.  Developers grow their skill when they are faced with
challenging tasks that they have not experienced.  Quality need not
suffer in such cases because peers guide, reviewers correct, and in
extreme cases, skilled developers overhaul.  Unqualified developers
exist in both models.  However, in cases of unqualified developers
writing open source production code, more reviewers may be finding
flaws and making improvements than a closed source project can
possibly justify hiring.

Furthermore, open source developers get the hind sight benefit of
seeing the changes even years after they've moved on, and learning
from it.

> When I say that neither of existing systems works, I mean that this
> selection does not happen. Firstly, there is no efficient mechanism
> of selection.  

Right, so you cannot be completely dependant on selection of talent
for quality products.

> Secondly, there is no motivation for people to become
> selected. Qualified programmers don't grow on trees. 

Who's to prevent a qualified programmer from producing open source?

> If the reward is to work 42 hours washing dishes and 30 contributing
> at night to a GNU project, then I don't see why students should
> spend 10+ years studying CS. They could become managers, advocates
> instead.

The unusual dishwasher case you bring up is not likely to be the
lifestyle of someone with an extensive formal education.  

> The attitude "it is no matter how much we pay them, because they
> would do the work anyway" is deeply rooted in both systems. This is
> why quality suffers.

Explain.  

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Sun, 16 Apr 2006 14:55:32 GMT, Justin Gombos wrote:

> On 2006-04-16, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>
>> If you open the fridge each morning and find beer there, should this
>> observation lead you the conclusion, that fridges brew beer?
> 
> Good example - faulty conclusion.  You can conclude from that
> observation that you have cold beer, and therefore don't need to make
> any changes to the fridge to ensure that it cools the beer, or changes
> to your procurement process for getting the beer.  Likewise, open
> source continues to grow substantially, so you can conclude that
> additional rewards are unnecessary for the growth to continue.

I can't conclude that without knowing the process. If I will not pay my
electricity bills, the fridge might stop cooling.

>>> From this observation alone, you know that there is a mechanism of
>>> rewards to promote such development.
>>
>> I don't know how it works. What if my brother, who loads the fridge
>> with beer would turn to abstinence?
> 
> Remedial action would then become necessary.  So if the open source
> community loses all its developers, only then will lack of rewards
> become a problem (and even then it's a matter of perception).  As of
> now, death of open source would be entirely hypothetical, and we're
> not living in a hypothetical world.

Death of open source is not my concern. Mine is sustainable growth, which
is the basis of our [western] civilisation. We observe what happens if it
just stops for a relatively short period of time. Europe's two major
countries Germany and France provide an excellent case. A projection of the
current state of software development in the future implies everybody to
become a programmer. It is a far more serious problem than terrorism.

>>> The openness of the code *is* one of many components of quality.
>>> Besides the quality built into the process of open source
>>> development, you also have the benefit of potentially millions of
>>> eyes looking at the product and discovering defects in the code.
>>
>> This is a model of wasting human resources in first place. 
> 
> Wasteful in what sense?

It is extensive, low productive, unsafe way. Million eyes is millions of
man hours spent. What is worse a community of dishwashers might spent
trillion years in building Perpetuum mobile, while one qualified physicist
could tell you in 1s, that it is rubbish. 

>> Secondly it effectively puts a limit to the complexity and quality
>> of the software.  
> 
> Quite the opposit.  It's the closed source model that limits
> complexity as well as quality.  You can be limited to the mental
> capacity of those hired, or you can be limited to the mental capacity
> of a subset of the world population, which can well exceed the size of
> any one company.  

It is a flawed argument. It is known as "brain amplifier", a concept of
gaining knowledge, recently bubbled again as genetic algorithms. Each cubic
meter of air contains encoded Britain encyclopedia as well as the Great
Theory of All. The problem with it, is that there is no way to select the
signal from noise. Averaging world population gives you Britney Spears, if
you are very lucky, it does not give you Albert Einstein.
 
>> Millions of incompetent eyes cannot replace an educated one. 
> 
> Who's to say "the educated one" is not an open source developer?

Because education is not for free. It is a huge investment on the side of
the society sponsoring it and on the side of people spending their time in
learning. It is a hard work, if you don't pay for it, you will get nothing.

>> I meant division of labor. Customer is somebody who is specialized to
>> produces something else. 
> 
> Even that definition is unrealistic.  Consumers are not necessarily so
> specialized that they're incapable of tailoring tools that are
> initially generic to help them do their job better.

It is so in software developing. The reason for that is an extremely low
technological level of. It is a transitional stage. Either it becomes a
normal engineering with clear division of labor and a very moderate number
of people involved in, or our civilization will collapse. What you propose
is similar to building pyramids by ancient Egyptians.

> But even if they
> were, open source consumers still have the option of hiring
> contractors to tailor their tools.  Closed source consumers are stuck
> with a black box, and must either modify the way they work to adapt to
> the tool, or try to motivate the vendor to modify it for them at a
> reasonable price, or hire someone to build the tool from the ground
> up.  So open source consumers have all the same options that closed
> source consumer have, and then some.

As I said above, the difference is marginal in my eyes. Remember the time
when each TV set, each audio system was shipped with printed electronic
circuit? How about the quality of those compared with the quality of modern
systems shipped with two page leaflet printed in 20 languages, explaining
where is the button "on/off" on the remote control? That's a technological
difference.

>> When I say that neither of existing systems works, I mean that this
>> selection does not happen. Firstly, there is no efficient mechanism
>> of selection.  
> 
> Right, so you cannot be completely dependant on selection of talent
> for quality products.

I must.
 
>> Secondly, there is no motivation for people to become
>> selected. Qualified programmers don't grow on trees. 
> 
> Who's to prevent a qualified programmer from producing open source?

A lack of a system that rewards qualification.

>> If the reward is to work 42 hours washing dishes and 30 contributing
>> at night to a GNU project, then I don't see why students should
>> spend 10+ years studying CS. They could become managers, advocates
>> instead.
> 
> The unusual dishwasher case you bring up is not likely to be the
> lifestyle of someone with an extensive formal education.  

What else have the community to offer? If you cannot sustain yourself by
programming, you will do something else. You might continue to program in
your spare time. But the next generation will drop the very idea of
becoming a programmer.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Sun, 16 Apr 2006 15:03:05 +0200, Georg Bauhaus wrote:

> On Sun, 2006-04-16 at 12:53 +0200, Dmitry A. Kazakov wrote:
>>  this is easily verifiable by observing growth
>>> rate of publically available open source software.
>> 
>> ... which bears all signs of pop-culture, by the way. Public involvement
>> destroys quality and even common sense. Turn MTV on, if you want an
>> example. Openness /= direct democracy.
> 
> pop-culture /= Public involvement,

Public involvement is the driving force behind the pop-culture.

> and open source does
> not imply absence of project rules. 
> Open source software does not by itself define how a project
> is run, obviously.

Exactly

>> They could become managers,
>> advocates instead.
> 
> Could you elaborate a bit how they could do this, and why they
> would want to do this?

Why shouldn't they? People adapt quickly. Their goals are formed by the
society. There always will be a pair of idiots working on compilers in
their spare time, but you cannot rely on exceptions.

>> The attitude "it is no matter how much we pay them, because they would do
>> the work anyway" is deeply rooted in both systems. This is why quality
>> suffers.
> 
> OK, some people want to maintain the impression that their high
> pay is justified. I'm not blaming them. But on which facts could we
> build a hypothesis that high wages guarantee high quality?

Not wages, but differentiation of according to individual contribution.

> Conversely, can you provide evidence that lower wages warrant lower
> quality of software?

There are strong historical evidences that lack of differentiation leads to
lower quality. Former SU suffered this problem. Economics based slavery
did.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Georg Bauhaus]

On Sun, 2006-04-16 at 19:59 +0200, Dmitry A. Kazakov wrote:
> >>Public involvement destroys quality and even common sense. [...]
> > pop-culture /= Public involvement,
> Public involvement is the driving force behind the pop-culture.

Do you mean "mass consumption" when you speak of public involvement?


> > and open source does
> > not imply absence of project rules. 
> > Open source software does not by itself define how a project
> > is run, obviously.
> 
> Exactly

So you agree that software quality, as affected by project
procedures, is orthogonal to open/closed source?


> >> They could become managers,
> >> advocates instead.
> > 
> > Could you elaborate a bit how they could do this, and why they
> > would want to do this?
> 
> Why shouldn't they? People adapt quickly. Their goals are formed by the
> society.

Who is society, then? And who forms the goals, as you say?


> Not wages, but differentiation of according to individual contribution.

And you think that you attract the best programmers by offering
high wages? That, together with meritocracy, has been shown
to be a myth. Job satisfaction is not guaranteed by just income.
The fact that SU professions in high regard could but
achieve a depressingly low standard income has not exactly
turned a physician into someone without education, knowledge,
and practice, has it? OTOH, with not much more than a little
cleverness, and overcoming certain scrupulous habits, you can
become fairly rich, in spite of producing mostly low quality crap...
So how is quality related to differentiation (and selection)
by income?

What are the software quality improvements to be derived
from differentiation by income? (Which I have nothing to say
against.) If you starve, you can't be productive, o.K..
But other than that, job satisfaction is not just money.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Sun, 16 Apr 2006 22:53:55 +0200, Georg Bauhaus wrote:

> On Sun, 2006-04-16 at 19:59 +0200, Dmitry A. Kazakov wrote:
>>>>Public involvement destroys quality and even common sense. [...]
>>> pop-culture /= Public involvement,
>> Public involvement is the driving force behind the pop-culture.
> 
> Do you mean "mass consumption" when you speak of public involvement?

Yes.
 
>>> and open source does
>>> not imply absence of project rules. 
>>> Open source software does not by itself define how a project
>>> is run, obviously.
>> 
>> Exactly
> 
> So you agree that software quality, as affected by project
> procedures, is orthogonal to open/closed source?

Yes. Open/close is orthogonal to quality. Openness might help in some
extraordinary cases, like mass media do with politicians. But it isn't a
reliable mechanism for micromanagement on daily basis.

>>>> They could become managers,
>>>> advocates instead.
>>> 
>>> Could you elaborate a bit how they could do this, and why they
>>> would want to do this?
>> 
>> Why shouldn't they? People adapt quickly. Their goals are formed by the
>> society.
> 
> Who is society, then? And who forms the goals, as you say?

Nobody. It just happens.

>> Not wages, but differentiation of according to individual contribution.
> 
> And you think that you attract the best programmers by offering
> high wages? That, together with meritocracy, has been shown
> to be a myth. Job satisfaction is not guaranteed by just income.

That might be true, but you should explain why low or no wages would
function better.

> The fact that SU professions in high regard could but
> achieve a depressingly low standard income has not exactly
> turned a physician into someone without education, knowledge,
> and practice, has it?

It did. The pressure to change the profession wasn't high, because all
wages were low. What happened is that positions required higher
qualification were assigned according to loyalty. If you consider the
history of any scientific or engineering institution in former SU, you will
see a slow process of decay as carrier makers elaborated their way up. In
two or so generations it was over.

> OTOH, with not much more than a little
> cleverness, and overcoming certain scrupulous habits, you can
> become fairly rich, in spite of producing mostly low quality crap...
> So how is quality related to differentiation (and selection)
> by income?

Wait, this exactly my point. The system allows you to become rich by
producing crap.

> What are the software quality improvements to be derived
> from differentiation by income? (Which I have nothing to say
> against.) If you starve, you can't be productive, o.K..
> But other than that, job satisfaction is not just money.

Money is a part of satisfaction. In our "capitalistic" society everything
is translated into money. I didn't even used this word, I talked about
rewarding. Anyway, if you can propose a better social system, which would
function, count me in. But in any system a contribution must be rewarded.
Use money, natural products, houri, whatever attracts people.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Randy Brukardt]

"Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
news:5Qc0g.12757$b06.5026@trnddc08...
> On 2006-04-12, Randy Brukardt <randy@rrsoftware.com> wrote:
> > "Justin Gombos" <rpbkbq.xax.gld@uluv.kbq> wrote in message
> > news:nT7%f.4699$7Z6.366@trnddc06...
> > ...
> >> > Which means no creations at all.
> >>
> >> You can't conclude that.  If that were a true statement, we would
> >> not have the rich library of GNU software that exists today.  Why?
> >> Because there's nothing to stop a GNU developer from having a day
> >> job.  I suspect most self supporting GNU developers have day jobs.
> >
> > But that's my point. Taken to it's limit, there could be no
> > well-paying "day jobs" for those GNU developers. After all, most of
> > them are employed at companies that get some benefit from the GNU
> > software. In the limit, where software was worth $0, there would be
> > no "day jobs" in fields that are even remotely related.
>
> How could there be no day job available for GNU developers?  Whatever
> your answer, it must be purely hypothetical,

Of course, I said "taken to the limit": that is, a world where there is only
open source software (but is otherwise essentially the same as today -
that's an assumption, but not much of one - there has been little change in
the overall economic picture in the last hundred year - industries and
governments come and go, but the basic drivers have remained the same).

> because GNU developers
> *do* have day jobs.  If they didn't, you'd have to explain how all the
> GNU developers have been surviving for the past 20+ years.

It's irrelevant, because most software has been developed by non-GNU
developers in the past. If there were *only* GNU developers, all of those
other "day jobs" at non-GNU developers would disappear.

> And what prevents such day jobs from being well paying?

Because almost all new jobs created are menial and minimum wage; the jobs
that require skill and thus are well-paying are disappearing. (At least for
those with engineering skills. Hardly anybody is truly great at more than
one thing, and you need to be great to make great software.)

> > If the day job is unrelated (or even only weakly related), then the
> > developers are either not developing great software, or are
> > short-changing someone (their employers, their families, themselves,
> > etc.) Great software requires at least some of the developers
> > putting a large amount of mental energy into the design and the
> > vision (and keeping to that design and vision). That's incompatible
> > with a "day job" that requires significant mental energy, which is
> > the vast majority of them.
>
> It seems you're making a lot of assumptions here, which in the end
> probably boils down to a very small group.  You're assuming a Henry
> Ford 40 hour work week, or greater.

I'm assuming that employment conditions remain similar to thosse of today.
In the US, IT people work an average of 48 hours a week. The average
American takes only 7 days of vacation. Those figures are getting worse, not
better.

> You're assuming these are mentally exhausting day jobs,

All jobs are mentally exhausting; if not for the work, for the boredom or
the office politics. Especially when you have to do them 10 hours a day.

> and you're assuming that the subject is easily fatigable.  You're also
> assuming that the mental energy
> required at work is the same type of mental energy that the subject
> would use in their GNU development (a lot of commercial software
> effort involves what I call metawork - administrative overhead and
> meetings talking about the work itself).

There is only one kind of mental energy, and it's a limited resource. I
realize that 20-somethings have more of it than 40-somethings like me, but
there are limits -- I hit them regularly when RRS was founded, and I still
hit them regularly.

...
> > You can cheat your employer, of course, but that's not a recipe for
> > a sustanable model. Nor is "work, program, sleep" a model for
> > healthy living.
>
> Healthy living is a different issue entirely.

Not at all; no system is sustainable if it is chewing up and spitting out
the workers. Quality software (quality anything) is not created with slave
labor, or people working 22 hour days -- no matter whether that is a labor
of love or a labor of money.

                          Randy.

Re: Making money on open source, if not by selling _support_, then how?

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:2429o5my9o4z.lue7cfjzu0nd$.dlg@40tude.net...
> On Sun, 16 Apr 2006 15:03:05 +0200, Georg Bauhaus wrote:
...
> There always will be a pair of idiots working on compilers in
> their spare time, but you cannot rely on exceptions.

Hey. I resemble that remark!! :-)

                Randy.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-18, Randy Brukardt <randy@rrsoftware.com> wrote:
>>
>> How could there be no day job available for GNU developers?
>> Whatever your answer, it must be purely hypothetical,
>
> Of course, I said "taken to the limit": that is, a world where there
> is only open source software

Such a case is as realistic as the world is hypothetical.

Which isn't to say it not useful to consider the extreme cases, but in
this case it also requires one to neglect the profitability of open
source entirely, and also presumes that day jobs are necessarily in
software development.

> (but is otherwise essentially the same as today - that's an
> assumption, but not much of one - there has been little change in
> the overall economic picture in the last hundred year - industries
> and governments come and go, but the basic drivers have remained the
> same).

The status quo is not even close to 100% open source.  

>> because GNU developers *do* have day jobs.  If they didn't, you'd
>> have to explain how all the GNU developers have been surviving for
>> the past 20+ years.
>
> It's irrelevant, because most software has been developed by non-GNU
> developers in the past. 

The fact that most software has been developed by non-GNU developers
says nothing to the contrary - nor does it support the claim that GNU
developers cannot sustain themselves.

> If there were *only* GNU developers, all of those other "day jobs"
> at non-GNU developers would disappear.

The same fear was expressed by assembly line workers during the
industrialization of the automotive industry.  You might say their
jobs "disappeared", or if you're more progressive you might say their
jobs were "replaced" by another industry.  Either way, you've failed
to show that open source doesn't put software tools in the consumers
hands.  

>> And what prevents such day jobs from being well paying?
>
> Because almost all new jobs created are menial and minimum wage; the
> jobs that require skill and thus are well-paying are
> disappearing. (At least for those with engineering skills. Hardly
> anybody is truly great at more than one thing, and you need to be
> great to make great software.)

This doesn't follow.  Who said the GNU developers day job must be
menial?  You seem to be implying that the only way to be paid well is
to develop closed source software.

> I'm assuming that employment conditions remain similar to thosse of
> today.  In the US, IT people work an average of 48 hours a week. The
> average American takes only 7 days of vacation. Those figures are
> getting worse, not better.

Your assumption is still faulty.  An /average/ American is not well
suited for GNU development.  Someone who is overworked is both
unsuitable for quality work, and further unlikely to voluntarily write
more software in their offtime.  

European developers can be more effective in the open source model
because they aren't pressed to the degree that Americans are.

>> You're assuming these are mentally exhausting day jobs,
>
> All jobs are mentally exhausting; if not for the work, for the
> boredom or the office politics. Especially when you have to do them
> 10 hours a day.

The key here is that you've made an assumption about the length of the
day job.  Someone who burns out doing 10 hour days is unlikely to
volunteer to produce code in their offtime.

> There is only one kind of mental energy, and it's a limited
> resource. I realize that 20-somethings have more of it than
> 40-somethings like me, but there are limits -- I hit them regularly
> when RRS was founded, and I still hit them regularly.

If a developer cannot balance energy expended on their day job and
energy in their offtime, again, unsuitable for GNU software
development.  A precondition for unpaid GNU development is not burning
out on the day job.  Folks who burn themselves out on their day jobs
are unfit for offtime s/w development - which isn't to say they're
excluded from open source participation, it simply means they must do
open source for profit to participate.

> no system is sustainable if it is chewing up and spitting out the
> workers. Quality software (quality anything) is not created with
> slave labor, or people working 22 hour days -- no matter whether
> that is a labor of love or a labor of money.

Exactly.  GNU software is about as far from "slave labor" as feasible,
because it's not only entirely voluntary, but in the absense of
extrinsic motivators it's easy to throttle back or even quit.  The GNU
developer can choose to create their works when they are rested, and
motivated with unused mental energy.  

OTOH, it's the jobs for hire that can demand excessive hours (in an
all or nothing fashion) and ultimately hinder software quality.  The
closed source developer faces this rigid contract, and must perform
even when they're in no condition to.  I believe this is another
contributor to the quality deficiency we see in closed source
products.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-16, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
> I can't conclude that without knowing the process. If I will not pay
> my electricity bills, the fridge might stop cooling.

Of course.  You have to understand a process before you can make
changes to it, which is why it's irrational to advocate extrinsic
rewards for developers without understanding why intrinsic motivation
has worked for the past 20 years.  You have no reasonable basis to all
promote additional extrinsic rewards.

> Death of open source is not my concern. Mine is sustainable growth,
> which is the basis of our [western] civilisation. We observe what
> happens if it just stops for a relatively short period of
> time. Europe's two major countries Germany and France provide an
> excellent case. A projection of the current state of software
> development in the future implies everybody to become a
> programmer. It is a far more serious problem than terrorism.

The meaning behind my use of the term "death" was lack of sustainable
growth.  And as I've pointed out, your concern is unfounded.  Simply
measuring the size of the sourceforge archives makes this evident.

>>>> The openness of the code *is* one of many components of quality.
>>>> Besides the quality built into the process of open source
>>>> development, you also have the benefit of potentially millions of
>>>> eyes looking at the product and discovering defects in the code.
>>>
>>> This is a model of wasting human resources in first place. 
>> 
>> Wasteful in what sense?
>
> It is extensive, low productive, unsafe way. Million eyes is
> millions of man hours spent. 

To be wasteful is to have expense w/out return.  Yet this is a reverse
case - getting a high return on little (if nothing) investment.  The
consumer pays *zero*, not a single man hour, and in return receives a
product that is very thoroughly debugged.

The waste you're referring to is paid by closed source consumers, who
pay for the same functionality multiple times over, and receive
nothing in exchange for the excessive investment.  Worse, because
effort is wasted on duplication, and resources within a single
controlling organization are limited, you don't receive products that
are thoroughly debugged.  So effort is wasted needlessly, while
simultaneously not enough effort is allocated to quality.  Most closed
source operations are lucky if they just get a couple reviewers
looking at a piece of code.

> What is worse a community of dishwashers might spent trillion years
> in building Perpetuum mobile, while one qualified physicist could
> tell you in 1s, that it is rubbish.

OTOH, if these dishwashers are qualified physicists, such an effort
would never occur.

>>> Secondly it effectively puts a limit to the complexity and quality
>>> of the software.
>> 
>> Quite the opposit.  It's the closed source model that limits
>> complexity as well as quality.  You can be limited to the mental
>> capacity of those hired, or you can be limited to the mental
>> capacity of a subset of the world population, which can well exceed
>> the size of any one company.
>
> It is a flawed argument. It is known as "brain amplifier", a concept
> of gaining knowledge, recently bubbled again as genetic
> algorithms. Each cubic meter of air contains encoded Britain
> encyclopedia as well as the Great Theory of All. The problem with
> it, is that there is no way to select the signal from
> noise. Averaging world population gives you Britney Spears, if you
> are very lucky, it does not give you Albert Einstein.

The benefit of brain quantity depends on the effort.  If the effort is
a creative one, and the component is small enough, then sure, your
stance would be reasonable because too many producers would become
obsticles.  But if the effort is to find software defects and report
them, then the benefit of signal / noise seperation is lost.  All good
encryption algorithms are publicised for this very purpose of
leveraging what you're calling "brain amplification."  You cannot
depend on one or even a handful of experts to find flaws in a complex
algorithm.  As intelligent as they may be, flaws are still overlooked.
So to ensure the strength of an algorithm, you *publish* it to get the
masses looking at it.  Among the masses, many who may fit your profile
of "Britney Spears" won't crack the algorithm (and in fact won't even
be looking at it), but they do nothing to stop the one who does find
the shortcut that cracks the puzzle (who may be an Einstein, but not
necessarily).

The open source community has the scalabilty to throttle "brain
amplification" to a level that serves the purpose, dividing large
creations into small pieces, or defect capturing en masse.  Whereas
closed source efforts are inherently limited - and often fail to work
efficiently with the limited resources that they do have.

>>> Millions of incompetent eyes cannot replace an educated one. 
>> 
>> Who's to say "the educated one" is not an open source developer?
>
> Because education is not for free. It is a huge investment on the
> side of the society sponsoring it and on the side of people spending
> their time in learning. It is a hard work, if you don't pay for it,
> you will get nothing.

All true statements.  However, such an investment does not prevent the
educated from creating GNU software.

>>> I meant division of labor. Customer is somebody who is specialized
>>> to produces something else.
>> 
>> Even that definition is unrealistic.  Consumers are not necessarily
>> so specialized that they're incapable of tailoring tools that are
>> initially generic to help them do their job better.
>
> It is so in software developing. The reason for that is an extremely
> low technological level of. It is a transitional stage. Either it
> becomes a normal engineering with clear division of labor and a very
> moderate number of people involved in, or our civilization will
> collapse. What you propose is similar to building pyramids by
> ancient Egyptians.

Certainly not, because there are enough similarites between the
different software products that if someone is so specialized that
they cannot work on the tools they use, they are likely to be
inadequite for doing their own job.  If you're so specialized in Ada
that you're incapable of using other languages, for example, then
you've failed as a developer to become enriched with concepts that
build on your area of specialization.  Learning Ada will improve the C
skills of a specialist who has no direct use for Ada.  As an Ada
developer, I often create non-ada tools to process the Ada code.  For
example, I might write a sed script to make a global edit to all my
Ada code.  If I were so specialized that I could not create my own
tools on the fly, or tailor my environment, I would not be as
productive.  If you're specialized to such a degree, you're not only a
minority, but impractical.  A good specialist *necessarily*
understands their tools.

Moreover, if you still insist on such a definition for "consumer", it
doesn't matter anyway because you've still failed to show that
consumers are hindered by having the extra ability to modify their
tools.

>> But even if they were, open source consumers still have the option
>> of hiring contractors to tailor their tools.  Closed source
>> consumers are stuck with a black box, and must either modify the
>> way they work to adapt to the tool, or try to motivate the vendor
>> to modify it for them at a reasonable price, or hire someone to
>> build the tool from the ground up.  So open source consumers have
>> all the same options that closed source consumer have, and then
>> some.
>
> As I said above, the difference is marginal in my eyes. Remember the
> time when each TV set, each audio system was shipped with printed
> electronic circuit? How about the quality of those compared with the
> quality of modern systems shipped with two page leaflet printed in
> 20 languages, explaining where is the button "on/off" on the remote
> control? That's a technological difference.

This is a false cause fallacy.  Modern products are developed from
more recent technological advances.

Reducing a consumers maintenance and modification options is not
necessarily better quality.  In fact I would claim the contrary - if a
the design prevents consumers from customizing the product, the
product is lower quality due to reduced useability.

>>> When I say that neither of existing systems works, I mean that this
>>> selection does not happen. Firstly, there is no efficient mechanism
>>> of selection.  
>> 
>> Right, so you cannot be completely dependant on selection of talent
>> for quality products.
>
> I must.

You conceded on imperfections in the selection process, then you said
you *must* limit your quality assurance solely to talent selection.
There is no tolerance in such a model for talent selection flaws, so
effectively you've put yourself at high risk for poor quality
production.

>>> Secondly, there is no motivation for people to become
>>> selected. Qualified programmers don't grow on trees.
>> 
>> Who's to prevent a qualified programmer from producing open source?
>
> A lack of a system that rewards qualification.

How?

>>> If the reward is to work 42 hours washing dishes and 30 contributing
>>> at night to a GNU project, then I don't see why students should
>>> spend 10+ years studying CS. They could become managers, advocates
>>> instead.
>> 
>> The unusual dishwasher case you bring up is not likely to be the
>> lifestyle of someone with an extensive formal education.  
>
> What else have the community to offer? 

Your position here is hinged on a false dilemma.  Washing dishes and
closed source software are not the only options for a day job.  There
are just too many jobs to list.  Browse through listings at
monster.com if you want to see what's out there.

> If you cannot sustain yourself by programming, you will do something
> else. You might continue to program in your spare time. But the next
> generation will drop the very idea of becoming a programmer.

Why?

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Justin Gombos]

On 2006-04-17, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>> And you think that you attract the best programmers by offering
>> high wages? That, together with meritocracy, has been shown to be a
>> myth. Job satisfaction is not guaranteed by just income.
>
> That might be true, but you should explain why low or no wages would
> function better.

You've misinterpretted Bauhaus.  Saying that high wages does not
necessarily attract the best talent is quite a bit different than
saying "low or no wages would function better".  I must start by
pointing out that this argument amounts to a strawman (because it
misrepresents Bauhaus' position), and it also contains a bipolar
logical fallacy (wages are not simply "high" or "low/nothing", at
least in developed nations).

Great talent includes passion for the discipline, and appealing to
such passion requires intrinsic motivators.  Significant extrinsic
motivation is more attractive to professionals who lack the passion -
and is in fact an essential component to this profile of creator.

To illustrate this, consider Jet Propulsion Laboratory.  JPL acquires
the top talent in aerospace, yet the pay is substandard.  JPL
engineers are capable of substantially higher income elsewhere, yet
JPL has a very low turnover.  So you have to ask, why aren't the
engineers leaving - the answer: because the intrinsic rewards are
high.  JPL has figured out how to attract top talent, and keep their
interest, essentially by making the work environment more academic
than what's typical.

The management style of creating a heavily micromanaged set of process
rules and simply paying employees high enough wages to ensure
compliance is the opposit extreme, and it's becoming obsolete
precisely because top talent is deterred from that model knowing that
workplaces like JPL exist.  

That's the short answer.  The long answer can be found in: "Intrinsic
Motivation at Work: Building Energy and Commitment" by Kenneth Thomas.

>> What are the software quality improvements to be derived
>> from differentiation by income? (Which I have nothing to say
>> against.) If you starve, you can't be productive, o.K..
>> But other than that, job satisfaction is not just money.
>
> Money is a part of satisfaction. In our "capitalistic" society
> everything is translated into money. I didn't even used this word, I
> talked about rewarding. Anyway, if you can propose a better social
> system, which would function, count me in. But in any system a
> contribution must be rewarded.  Use money, natural products, houri,
> whatever attracts people.

Under a capitalist system, you first have to accept the fact that you
only have to outperform the best competitor.  If you're rewarding
employees with an order of magnitude more pay (which according to you
would get the best programmers), and you are also offering high
intrinsic rewards, then you're a poor business person, because you're
not maximizing profit - in which case you'll be replaced by someone
who does maximize profit.  It's a balance that you can't escape from.
Under this system companies that have substantial intrinsic motivators
will pay lower wages, because they can.  And they will still retain
top talent.

-- 
PM instructions: do a C4esar Ciph3r on my address; retain punctuation.

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Wed, 19 Apr 2006 20:38:49 GMT, Justin Gombos wrote:

> To illustrate this, consider Jet Propulsion Laboratory.  JPL acquires
> the top talent in aerospace, yet the pay is substandard.  JPL
> engineers are capable of substantially higher income elsewhere, yet
> JPL has a very low turnover.  So you have to ask, why aren't the
> engineers leaving - the answer: because the intrinsic rewards are
> high.  JPL has figured out how to attract top talent, and keep their
> interest, essentially by making the work environment more academic
> than what's typical.

This example only proves my point. The reward of having access to expensive
men's toys of JPL, the reward of being one of "distinguished those"
compensate less competitive wages. A dishwasher has nothing of that. Then,
there can be only one JPL. The system should work for all or at least for
most of laboratories. So other laboratories should provide something else,
higher wages, a system of bonuses, attractive location, 35 hours week etc,
to get qualified personnel. Otherwise, they must be closed.

> Under a capitalist system, you first have to accept the fact that you
> only have to outperform the best competitor.

Yes. This is why autocratic and totalitarian systems are better in
achieving individual goals in a short period of time. They perform
depth-first search. But they always loose in general.

> If you're rewarding
> employees with an order of magnitude more pay (which according to you
> would get the best programmers), and you are also offering high
> intrinsic rewards, then you're a poor business person, because you're
> not maximizing profit - in which case you'll be replaced by someone
> who does maximize profit.

Yes. This is bad for me, but it is good for the society. Consider it as an
intrinsic motivation. (:-))

> It's a balance that you can't escape from.

Should I? Programmers positions will be inevitably cut, for the reasons I
described in another post.

> Under this system companies that have substantial intrinsic motivators
> will pay lower wages, because they can.  And they will still retain
> top talent.

Nothing is for free. Intrinsic motivations have concrete cost. See another
post.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Making money on open source, if not by selling _support_, then how?

[Dmitry A. Kazakov]

On Wed, 19 Apr 2006 18:17:48 GMT, Justin Gombos wrote:

> On 2006-04-16, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>
>> I can't conclude that without knowing the process. If I will not pay
>> my electricity bills, the fridge might stop cooling.
> 
> Of course.  You have to understand a process before you can make
> changes to it, which is why it's irrational to advocate extrinsic
> rewards for developers without understanding why intrinsic motivation
> has worked for the past 20 years.  You have no reasonable basis to all
> promote additional extrinsic rewards.

Additional? I challenge this division. There is no such thing as intrinsic
motivation, in the sense that it cannot be transferred from one person to
another. The sources of any such motivation are extrinsic. Let's count all
these sources, their social and economical cost. Then we can really judge.

>> Death of open source is not my concern. Mine is sustainable growth,
>> which is the basis of our [western] civilisation. We observe what
>> happens if it just stops for a relatively short period of
>> time. Europe's two major countries Germany and France provide an
>> excellent case. A projection of the current state of software
>> development in the future implies everybody to become a
>> programmer. It is a far more serious problem than terrorism.
> 
> The meaning behind my use of the term "death" was lack of sustainable
> growth.  And as I've pointed out, your concern is unfounded.  Simply
> measuring the size of the sourceforge archives makes this evident.

Is your point that the exponential demand on software will be covered by
sourceforge projects? I take my hat off to your optimism.

>>>>> The openness of the code *is* one of many components of quality.
>>>>> Besides the quality built into the process of open source
>>>>> development, you also have the benefit of potentially millions of
>>>>> eyes looking at the product and discovering defects in the code.
>>>>
>>>> This is a model of wasting human resources in first place. 
>>> 
>>> Wasteful in what sense?
>>
>> It is extensive, low productive, unsafe way. Million eyes is
>> millions of man hours spent. 
> 
> To be wasteful is to have expense w/out return.  Yet this is a reverse
> case - getting a high return on little (if nothing) investment.  The
> consumer pays *zero*, not a single man hour, and in return receives a
> product that is very thoroughly debugged.

You consider here only one side, of the consumer. But for humankind nothing
is for free. Each millisecond of everybody counts. Million eyes where only
two are needed is disastrous. This time should be spent on space
exploration, fusion reactors, human genome, nanotechnology etc. If
sourceforge indeed grows, as you say, then we are lost.
 
>> What is worse a community of dishwashers might spent trillion years
>> in building Perpetuum mobile, while one qualified physicist could
>> tell you in 1s, that it is rubbish.
> 
> OTOH, if these dishwashers are qualified physicists, such an effort
> would never occur.

Is it normal when qualified physicists wash dishes? I don't ask you to give
any moral assessment, just note that any self-regulating system atrophies
unused limbs. The society of dishwashers cannot be competent in physics for
any long period of time.

>>>> Secondly it effectively puts a limit to the complexity and quality
>>>> of the software.
>>> 
>>> Quite the opposit.  It's the closed source model that limits
>>> complexity as well as quality.  You can be limited to the mental
>>> capacity of those hired, or you can be limited to the mental
>>> capacity of a subset of the world population, which can well exceed
>>> the size of any one company.
>>
>> It is a flawed argument. It is known as "brain amplifier", a concept
>> of gaining knowledge, recently bubbled again as genetic
>> algorithms. Each cubic meter of air contains encoded Britain
>> encyclopedia as well as the Great Theory of All. The problem with
>> it, is that there is no way to select the signal from
>> noise. Averaging world population gives you Britney Spears, if you
>> are very lucky, it does not give you Albert Einstein.
> 
> The benefit of brain quantity depends on the effort.  If the effort is
> a creative one, and the component is small enough, then sure, your
> stance would be reasonable because too many producers would become
> obsticles.  But if the effort is to find software defects and report
> them, then the benefit of signal / noise seperation is lost.  All good
> encryption algorithms are publicised for this very purpose of
> leveraging what you're calling "brain amplification."  You cannot
> depend on one or even a handful of experts to find flaws in a complex
> algorithm.  As intelligent as they may be, flaws are still overlooked.
> So to ensure the strength of an algorithm, you *publish* it to get the
> masses looking at it.  Among the masses, many who may fit your profile
> of "Britney Spears" won't crack the algorithm (and in fact won't even
> be looking at it), but they do nothing to stop the one who does find
> the shortcut that cracks the puzzle (who may be an Einstein, but not
> necessarily).
> 
> The open source community has the scalabilty to throttle "brain
> amplification" to a level that serves the purpose, dividing large
> creations into small pieces, or defect capturing en masse.  Whereas
> closed source efforts are inherently limited - and often fail to work
> efficiently with the limited resources that they do have.

Nope. There are trivial statistical observations, why this does not work.
You can't solve exponential problems by brute force. Nine pregnant women
don't give birth in one month. 

>>>> I meant division of labor. Customer is somebody who is specialized
>>>> to produces something else.
>>> 
>>> Even that definition is unrealistic.  Consumers are not necessarily
>>> so specialized that they're incapable of tailoring tools that are
>>> initially generic to help them do their job better.
>>
>> It is so in software developing. The reason for that is an extremely
>> low technological level of. It is a transitional stage. Either it
>> becomes a normal engineering with clear division of labor and a very
>> moderate number of people involved in, or our civilization will
>> collapse. What you propose is similar to building pyramids by
>> ancient Egyptians.
> 
> Certainly not, because there are enough similarites between the
> different software products that if someone is so specialized that
> they cannot work on the tools they use, they are likely to be
> inadequite for doing their own job.  If you're so specialized in Ada
> that you're incapable of using other languages, for example, then
> you've failed as a developer to become enriched with concepts that
> build on your area of specialization.  Learning Ada will improve the C
> skills of a specialist who has no direct use for Ada.  As an Ada
> developer, I often create non-ada tools to process the Ada code.  For
> example, I might write a sed script to make a global edit to all my
> Ada code.  If I were so specialized that I could not create my own
> tools on the fly, or tailor my environment, I would not be as
> productive.  If you're specialized to such a degree, you're not only a
> minority, but impractical.  A good specialist *necessarily*
> understands their tools.

Again, if it is so, the we as humans have a damn great problem. You are
talking about different strategies of feeding horses, where the problem to
solve is the world-wide transportation system. If programming become
engineering, that will not be done in any of existing languages, even in
Ada. How can you assume that a jet propulsion laboratory would keep on
designing bridles?

> Moreover, if you still insist on such a definition for "consumer", it
> doesn't matter anyway because you've still failed to show that
> consumers are hindered by having the extra ability to modify their
> tools.

I never said this. Consumers should have an ability of, they shall not have
any necessity of. You can modify your car, but you needn't to. A system
where everybody have to repair his/her car is badly ill, former SU was
such.

>>>> When I say that neither of existing systems works, I mean that this
>>>> selection does not happen. Firstly, there is no efficient mechanism
>>>> of selection.  
>>> 
>>> Right, so you cannot be completely dependant on selection of talent
>>> for quality products.
>>
>> I must.
> 
> You conceded on imperfections in the selection process, then you said
> you *must* limit your quality assurance solely to talent selection.
> There is no tolerance in such a model for talent selection flaws, so
> effectively you've put yourself at high risk for poor quality
> production.

How so? Under any circumstances a system that selects better candidates for
each position is better.

>>>> Secondly, there is no motivation for people to become
>>>> selected. Qualified programmers don't grow on trees.
>>> 
>>> Who's to prevent a qualified programmer from producing open source?
>>
>> A lack of a system that rewards qualification.
> 
> How?

Why should they?

> Your position here is hinged on a false dilemma.  Washing dishes and
> closed source software are not the only options for a day job.  There
> are just too many jobs to list.  Browse through listings at
> monster.com if you want to see what's out there.
> 
>> If you cannot sustain yourself by programming, you will do something
>> else. You might continue to program in your spare time. But the next
>> generation will drop the very idea of becoming a programmer.
> 
> Why?

I don't know, it just works this way.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de