* Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? @ 2006-04-01 13:47 Doobs 2006-04-01 14:33 ` Jeffrey Creem ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Doobs @ 2006-04-01 13:47 UTC (permalink / raw) 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..... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 13:47 Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? Doobs @ 2006-04-01 14:33 ` Jeffrey Creem 2006-04-01 16:52 ` Doobs 2006-04-01 17:08 ` Florian Weimer 2006-04-04 1:23 ` Randy Brukardt 2 siblings, 1 reply; 69+ messages in thread From: Jeffrey Creem @ 2006-04-01 14:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 14:33 ` Jeffrey Creem @ 2006-04-01 16:52 ` Doobs 2006-04-01 17:56 ` Martin Krischik 2006-04-01 18:04 ` Dmitry A. Kazakov 0 siblings, 2 replies; 69+ messages in thread From: Doobs @ 2006-04-01 16:52 UTC (permalink / raw) ">> 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 16:52 ` Doobs @ 2006-04-01 17:56 ` Martin Krischik 2006-04-01 18:04 ` Dmitry A. Kazakov 1 sibling, 0 replies; 69+ messages in thread From: Martin Krischik @ 2006-04-01 17:56 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 16:52 ` Doobs 2006-04-01 17:56 ` Martin Krischik @ 2006-04-01 18:04 ` Dmitry A. Kazakov 1 sibling, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-01 18:04 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 13:47 Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? Doobs 2006-04-01 14:33 ` Jeffrey Creem @ 2006-04-01 17:08 ` Florian Weimer 2006-04-01 17:54 ` Doobs 2006-04-04 1:23 ` Randy Brukardt 2 siblings, 1 reply; 69+ messages in thread From: Florian Weimer @ 2006-04-01 17:08 UTC (permalink / raw) > 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 17:08 ` Florian Weimer @ 2006-04-01 17:54 ` Doobs 2006-04-01 18:19 ` Doobs 0 siblings, 1 reply; 69+ messages in thread From: Doobs @ 2006-04-01 17:54 UTC (permalink / raw) "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... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 17:54 ` Doobs @ 2006-04-01 18:19 ` Doobs 2006-04-01 20:01 ` Jeffrey Creem 2006-04-01 20:57 ` Dmitry A. Kazakov 0 siblings, 2 replies; 69+ messages in thread From: Doobs @ 2006-04-01 18:19 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 18:19 ` Doobs @ 2006-04-01 20:01 ` Jeffrey Creem 2006-04-01 21:33 ` Doobs 2006-04-01 20:57 ` Dmitry A. Kazakov 1 sibling, 1 reply; 69+ messages in thread From: Jeffrey Creem @ 2006-04-01 20:01 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 20:01 ` Jeffrey Creem @ 2006-04-01 21:33 ` Doobs 2006-04-03 12:25 ` Gerd 0 siblings, 1 reply; 69+ messages in thread From: Doobs @ 2006-04-01 21:33 UTC (permalink / raw) >>>>>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!)..... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 21:33 ` Doobs @ 2006-04-03 12:25 ` Gerd 0 siblings, 0 replies; 69+ messages in thread From: Gerd @ 2006-04-03 12:25 UTC (permalink / raw) 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; ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 18:19 ` Doobs 2006-04-01 20:01 ` Jeffrey Creem @ 2006-04-01 20:57 ` Dmitry A. Kazakov 1 sibling, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-01 20:57 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-01 13:47 Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? Doobs 2006-04-01 14:33 ` Jeffrey Creem 2006-04-01 17:08 ` Florian Weimer @ 2006-04-04 1:23 ` Randy Brukardt 2006-04-10 1:42 ` Justin Gombos 2 siblings, 1 reply; 69+ messages in thread From: Randy Brukardt @ 2006-04-04 1:23 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-04 1:23 ` Randy Brukardt @ 2006-04-10 1:42 ` Justin Gombos 2006-04-10 20:12 ` Randy Brukardt 0 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-10 1:42 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? 2006-04-10 1:42 ` Justin Gombos @ 2006-04-10 20:12 ` Randy Brukardt 2006-04-11 13:54 ` Making money on open source, if not by selling _support_, then how? Marc A. Criley 0 siblings, 1 reply; 69+ messages in thread From: Randy Brukardt @ 2006-04-10 20:12 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Making money on open source, if not by selling _support_, then how? 2006-04-10 20:12 ` Randy Brukardt @ 2006-04-11 13:54 ` Marc A. Criley 2006-04-11 15:13 ` Justin Gombos ` (3 more replies) 0 siblings, 4 replies; 69+ messages in thread From: Marc A. Criley @ 2006-04-11 13:54 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 13:54 ` Making money on open source, if not by selling _support_, then how? Marc A. Criley @ 2006-04-11 15:13 ` Justin Gombos 2006-04-11 16:22 ` Dmitry A. Kazakov 2006-04-11 15:34 ` Justin Gombos ` (2 subsequent siblings) 3 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-11 15:13 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 15:13 ` Justin Gombos @ 2006-04-11 16:22 ` Dmitry A. Kazakov 2006-04-11 17:56 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-11 16:22 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 16:22 ` Dmitry A. Kazakov @ 2006-04-11 17:56 ` Justin Gombos 2006-04-11 18:38 ` Georg Bauhaus ` (2 more replies) 0 siblings, 3 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-11 17:56 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 17:56 ` Justin Gombos @ 2006-04-11 18:38 ` Georg Bauhaus 2006-04-12 13:59 ` Justin Gombos 2006-04-11 19:59 ` Randy Brukardt 2006-04-12 8:32 ` Dmitry A. Kazakov 2 siblings, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-11 18:38 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 18:38 ` Georg Bauhaus @ 2006-04-12 13:59 ` Justin Gombos 2006-04-12 14:39 ` Georg Bauhaus 2006-04-12 17:07 ` Larry Kilgallen 0 siblings, 2 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-12 13:59 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 13:59 ` Justin Gombos @ 2006-04-12 14:39 ` Georg Bauhaus 2006-04-15 19:33 ` Justin Gombos 2006-04-12 17:07 ` Larry Kilgallen 1 sibling, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-12 14:39 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 14:39 ` Georg Bauhaus @ 2006-04-15 19:33 ` Justin Gombos 0 siblings, 0 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-15 19:33 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 13:59 ` Justin Gombos 2006-04-12 14:39 ` Georg Bauhaus @ 2006-04-12 17:07 ` Larry Kilgallen 2006-04-13 3:16 ` Justin Gombos 1 sibling, 1 reply; 69+ messages in thread From: Larry Kilgallen @ 2006-04-12 17:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 17:07 ` Larry Kilgallen @ 2006-04-13 3:16 ` Justin Gombos 0 siblings, 0 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-13 3:16 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 17:56 ` Justin Gombos 2006-04-11 18:38 ` Georg Bauhaus @ 2006-04-11 19:59 ` Randy Brukardt 2006-04-11 20:18 ` Ed Falis ` (2 more replies) 2006-04-12 8:32 ` Dmitry A. Kazakov 2 siblings, 3 replies; 69+ messages in thread From: Randy Brukardt @ 2006-04-11 19:59 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 19:59 ` Randy Brukardt @ 2006-04-11 20:18 ` Ed Falis 2006-04-12 14:10 ` Justin Gombos 2006-04-12 19:27 ` Martin Dowie 2 siblings, 0 replies; 69+ messages in thread From: Ed Falis @ 2006-04-11 20:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 19:59 ` Randy Brukardt 2006-04-11 20:18 ` Ed Falis @ 2006-04-12 14:10 ` Justin Gombos 2006-04-12 20:57 ` Randy Brukardt 2006-04-12 19:27 ` Martin Dowie 2 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-12 14:10 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 14:10 ` Justin Gombos @ 2006-04-12 20:57 ` Randy Brukardt 2006-04-15 20:37 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Randy Brukardt @ 2006-04-12 20:57 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 20:57 ` Randy Brukardt @ 2006-04-15 20:37 ` Justin Gombos 2006-04-18 0:24 ` Randy Brukardt 0 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-15 20:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-15 20:37 ` Justin Gombos @ 2006-04-18 0:24 ` Randy Brukardt 2006-04-18 16:02 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Randy Brukardt @ 2006-04-18 0:24 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-18 0:24 ` Randy Brukardt @ 2006-04-18 16:02 ` Justin Gombos 0 siblings, 0 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-18 16:02 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 19:59 ` Randy Brukardt 2006-04-11 20:18 ` Ed Falis 2006-04-12 14:10 ` Justin Gombos @ 2006-04-12 19:27 ` Martin Dowie 2 siblings, 0 replies; 69+ messages in thread From: Martin Dowie @ 2006-04-12 19:27 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 17:56 ` Justin Gombos 2006-04-11 18:38 ` Georg Bauhaus 2006-04-11 19:59 ` Randy Brukardt @ 2006-04-12 8:32 ` Dmitry A. Kazakov 2006-04-12 11:23 ` Georg Bauhaus 2006-04-13 2:58 ` Justin Gombos 2 siblings, 2 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-12 8:32 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 8:32 ` Dmitry A. Kazakov @ 2006-04-12 11:23 ` Georg Bauhaus 2006-04-12 15:34 ` Dmitry A. Kazakov 2006-04-13 2:58 ` Justin Gombos 1 sibling, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-12 11:23 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 11:23 ` Georg Bauhaus @ 2006-04-12 15:34 ` Dmitry A. Kazakov 2006-04-12 17:11 ` Georg Bauhaus 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-12 15:34 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 15:34 ` Dmitry A. Kazakov @ 2006-04-12 17:11 ` Georg Bauhaus 2006-04-12 19:37 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-12 17:11 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 17:11 ` Georg Bauhaus @ 2006-04-12 19:37 ` Dmitry A. Kazakov 2006-04-12 21:56 ` Georg Bauhaus 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-12 19:37 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 19:37 ` Dmitry A. Kazakov @ 2006-04-12 21:56 ` Georg Bauhaus 2006-04-13 9:17 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-12 21:56 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 21:56 ` Georg Bauhaus @ 2006-04-13 9:17 ` Dmitry A. Kazakov 2006-04-13 14:18 ` Georg Bauhaus 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-13 9:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-13 9:17 ` Dmitry A. Kazakov @ 2006-04-13 14:18 ` Georg Bauhaus 2006-04-14 10:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-13 14:18 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-13 14:18 ` Georg Bauhaus @ 2006-04-14 10:01 ` Dmitry A. Kazakov 2006-04-14 12:55 ` Georg Bauhaus 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-14 10:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-14 10:01 ` Dmitry A. Kazakov @ 2006-04-14 12:55 ` Georg Bauhaus 2006-04-15 10:13 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-14 12:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-14 12:55 ` Georg Bauhaus @ 2006-04-15 10:13 ` Dmitry A. Kazakov 2006-04-15 18:07 ` Georg Bauhaus 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-15 10:13 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-15 10:13 ` Dmitry A. Kazakov @ 2006-04-15 18:07 ` Georg Bauhaus 0 siblings, 0 replies; 69+ messages in thread From: Georg Bauhaus @ 2006-04-15 18:07 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-12 8:32 ` Dmitry A. Kazakov 2006-04-12 11:23 ` Georg Bauhaus @ 2006-04-13 2:58 ` Justin Gombos 2006-04-13 9:17 ` Dmitry A. Kazakov 1 sibling, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-13 2:58 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-13 2:58 ` Justin Gombos @ 2006-04-13 9:17 ` Dmitry A. Kazakov 2006-04-15 21:17 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-13 9:17 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-13 9:17 ` Dmitry A. Kazakov @ 2006-04-15 21:17 ` Justin Gombos 2006-04-16 10:53 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-15 21:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-15 21:17 ` Justin Gombos @ 2006-04-16 10:53 ` Dmitry A. Kazakov 2006-04-16 13:03 ` Georg Bauhaus 2006-04-16 14:55 ` Justin Gombos 0 siblings, 2 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-16 10:53 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 10:53 ` Dmitry A. Kazakov @ 2006-04-16 13:03 ` Georg Bauhaus 2006-04-16 17:59 ` Dmitry A. Kazakov 2006-04-16 14:55 ` Justin Gombos 1 sibling, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-16 13:03 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 13:03 ` Georg Bauhaus @ 2006-04-16 17:59 ` Dmitry A. Kazakov 2006-04-16 20:53 ` Georg Bauhaus 2006-04-18 0:29 ` Randy Brukardt 0 siblings, 2 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-16 17:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 17:59 ` Dmitry A. Kazakov @ 2006-04-16 20:53 ` Georg Bauhaus 2006-04-17 9:16 ` Dmitry A. Kazakov 2006-04-18 0:29 ` Randy Brukardt 1 sibling, 1 reply; 69+ messages in thread From: Georg Bauhaus @ 2006-04-16 20:53 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 20:53 ` Georg Bauhaus @ 2006-04-17 9:16 ` Dmitry A. Kazakov 2006-04-19 20:38 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-17 9:16 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-17 9:16 ` Dmitry A. Kazakov @ 2006-04-19 20:38 ` Justin Gombos 2006-04-20 18:01 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-19 20:38 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-19 20:38 ` Justin Gombos @ 2006-04-20 18:01 ` Dmitry A. Kazakov 0 siblings, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-20 18:01 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 17:59 ` Dmitry A. Kazakov 2006-04-16 20:53 ` Georg Bauhaus @ 2006-04-18 0:29 ` Randy Brukardt 1 sibling, 0 replies; 69+ messages in thread From: Randy Brukardt @ 2006-04-18 0:29 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 10:53 ` Dmitry A. Kazakov 2006-04-16 13:03 ` Georg Bauhaus @ 2006-04-16 14:55 ` Justin Gombos 2006-04-16 17:59 ` Dmitry A. Kazakov 1 sibling, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-16 14:55 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 14:55 ` Justin Gombos @ 2006-04-16 17:59 ` Dmitry A. Kazakov 2006-04-19 18:17 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-16 17:59 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-16 17:59 ` Dmitry A. Kazakov @ 2006-04-19 18:17 ` Justin Gombos 2006-04-20 18:07 ` Dmitry A. Kazakov 0 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-19 18:17 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-19 18:17 ` Justin Gombos @ 2006-04-20 18:07 ` Dmitry A. Kazakov 0 siblings, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-20 18:07 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 13:54 ` Making money on open source, if not by selling _support_, then how? Marc A. Criley 2006-04-11 15:13 ` Justin Gombos @ 2006-04-11 15:34 ` Justin Gombos 2006-04-12 2:59 ` Steve 2006-04-13 7:41 ` Jean-Pierre Rosen 3 siblings, 0 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-11 15:34 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 13:54 ` Making money on open source, if not by selling _support_, then how? Marc A. Criley 2006-04-11 15:13 ` Justin Gombos 2006-04-11 15:34 ` Justin Gombos @ 2006-04-12 2:59 ` Steve 2006-04-13 7:41 ` Jean-Pierre Rosen 3 siblings, 0 replies; 69+ messages in thread From: Steve @ 2006-04-12 2:59 UTC (permalink / raw) "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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-11 13:54 ` Making money on open source, if not by selling _support_, then how? Marc A. Criley ` (2 preceding siblings ...) 2006-04-12 2:59 ` Steve @ 2006-04-13 7:41 ` Jean-Pierre Rosen 2006-04-13 13:18 ` Marc A. Criley 3 siblings, 1 reply; 69+ messages in thread From: Jean-Pierre Rosen @ 2006-04-13 7:41 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-13 7:41 ` Jean-Pierre Rosen @ 2006-04-13 13:18 ` Marc A. Criley 2006-04-13 13:35 ` Dmitry A. Kazakov 2006-04-13 13:57 ` Making money on open source, if not by selling _support_, then Larry Kilgallen 0 siblings, 2 replies; 69+ messages in thread From: Marc A. Criley @ 2006-04-13 13:18 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then how? 2006-04-13 13:18 ` Marc A. Criley @ 2006-04-13 13:35 ` Dmitry A. Kazakov 2006-04-13 13:57 ` Making money on open source, if not by selling _support_, then Larry Kilgallen 1 sibling, 0 replies; 69+ messages in thread From: Dmitry A. Kazakov @ 2006-04-13 13:35 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then 2006-04-13 13:18 ` Marc A. Criley 2006-04-13 13:35 ` Dmitry A. Kazakov @ 2006-04-13 13:57 ` Larry Kilgallen 2006-04-13 19:37 ` Justin Gombos 1 sibling, 1 reply; 69+ messages in thread From: Larry Kilgallen @ 2006-04-13 13:57 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then 2006-04-13 13:57 ` Making money on open source, if not by selling _support_, then Larry Kilgallen @ 2006-04-13 19:37 ` Justin Gombos 2006-04-13 21:02 ` Larry Kilgallen 0 siblings, 1 reply; 69+ messages in thread From: Justin Gombos @ 2006-04-13 19:37 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then 2006-04-13 19:37 ` Justin Gombos @ 2006-04-13 21:02 ` Larry Kilgallen 2006-04-14 2:49 ` Justin Gombos 0 siblings, 1 reply; 69+ messages in thread From: Larry Kilgallen @ 2006-04-13 21:02 UTC (permalink / raw) 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). ^ permalink raw reply [flat|nested] 69+ messages in thread
* Re: Making money on open source, if not by selling _support_, then 2006-04-13 21:02 ` Larry Kilgallen @ 2006-04-14 2:49 ` Justin Gombos 0 siblings, 0 replies; 69+ messages in thread From: Justin Gombos @ 2006-04-14 2:49 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 69+ messages in thread
end of thread, other threads:[~2006-04-20 18:07 UTC | newest] Thread overview: 69+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-04-01 13:47 Any way of persuading GNAT/GCC to implement a true overlay and not a pointer? Doobs 2006-04-01 14:33 ` Jeffrey Creem 2006-04-01 16:52 ` Doobs 2006-04-01 17:56 ` Martin Krischik 2006-04-01 18:04 ` Dmitry A. Kazakov 2006-04-01 17:08 ` Florian Weimer 2006-04-01 17:54 ` Doobs 2006-04-01 18:19 ` Doobs 2006-04-01 20:01 ` Jeffrey Creem 2006-04-01 21:33 ` Doobs 2006-04-03 12:25 ` Gerd 2006-04-01 20:57 ` Dmitry A. Kazakov 2006-04-04 1:23 ` Randy Brukardt 2006-04-10 1:42 ` Justin Gombos 2006-04-10 20:12 ` Randy Brukardt 2006-04-11 13:54 ` Making money on open source, if not by selling _support_, then how? Marc A. Criley 2006-04-11 15:13 ` Justin Gombos 2006-04-11 16:22 ` Dmitry A. Kazakov 2006-04-11 17:56 ` Justin Gombos 2006-04-11 18:38 ` Georg Bauhaus 2006-04-12 13:59 ` Justin Gombos 2006-04-12 14:39 ` Georg Bauhaus 2006-04-15 19:33 ` Justin Gombos 2006-04-12 17:07 ` Larry Kilgallen 2006-04-13 3:16 ` Justin Gombos 2006-04-11 19:59 ` Randy Brukardt 2006-04-11 20:18 ` Ed Falis 2006-04-12 14:10 ` Justin Gombos 2006-04-12 20:57 ` Randy Brukardt 2006-04-15 20:37 ` Justin Gombos 2006-04-18 0:24 ` Randy Brukardt 2006-04-18 16:02 ` Justin Gombos 2006-04-12 19:27 ` Martin Dowie 2006-04-12 8:32 ` Dmitry A. Kazakov 2006-04-12 11:23 ` Georg Bauhaus 2006-04-12 15:34 ` Dmitry A. Kazakov 2006-04-12 17:11 ` Georg Bauhaus 2006-04-12 19:37 ` Dmitry A. Kazakov 2006-04-12 21:56 ` Georg Bauhaus 2006-04-13 9:17 ` Dmitry A. Kazakov 2006-04-13 14:18 ` Georg Bauhaus 2006-04-14 10:01 ` Dmitry A. Kazakov 2006-04-14 12:55 ` Georg Bauhaus 2006-04-15 10:13 ` Dmitry A. Kazakov 2006-04-15 18:07 ` Georg Bauhaus 2006-04-13 2:58 ` Justin Gombos 2006-04-13 9:17 ` Dmitry A. Kazakov 2006-04-15 21:17 ` Justin Gombos 2006-04-16 10:53 ` Dmitry A. Kazakov 2006-04-16 13:03 ` Georg Bauhaus 2006-04-16 17:59 ` Dmitry A. Kazakov 2006-04-16 20:53 ` Georg Bauhaus 2006-04-17 9:16 ` Dmitry A. Kazakov 2006-04-19 20:38 ` Justin Gombos 2006-04-20 18:01 ` Dmitry A. Kazakov 2006-04-18 0:29 ` Randy Brukardt 2006-04-16 14:55 ` Justin Gombos 2006-04-16 17:59 ` Dmitry A. Kazakov 2006-04-19 18:17 ` Justin Gombos 2006-04-20 18:07 ` Dmitry A. Kazakov 2006-04-11 15:34 ` Justin Gombos 2006-04-12 2:59 ` Steve 2006-04-13 7:41 ` Jean-Pierre Rosen 2006-04-13 13:18 ` Marc A. Criley 2006-04-13 13:35 ` Dmitry A. Kazakov 2006-04-13 13:57 ` Making money on open source, if not by selling _support_, then Larry Kilgallen 2006-04-13 19:37 ` Justin Gombos 2006-04-13 21:02 ` Larry Kilgallen 2006-04-14 2:49 ` Justin Gombos
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox