Class 6: The Magic Cauldron Discussion

Notes for 6/13/2013

Transcript

1. The Magic Cauldron Discussion Class Six: June 13, 2013
2. Let’s  Be  Prac,cal:  Economics What  is  the  magic  cauldron? When  should  one  be  open  and  when  should  one  be   closed? What  are  some  arguments  for/against  each  approach? What  do  you  think  of  the  quote,  “secrecy  is  the  enemy   of  quality”? What  is  the  “open  source  doomsday”  scenario?
3. Use  vs.  Sale  Value The  use  value  of  a  program  is  its  economic  value  as  a   tool,  a  produc@vity  mul@plier.  E.g.  it  saves  you  @me. The  sale  value  of  a  program  is  its  value  as  a  salable   commodity.   In  professional  economist-­‐speak,  sale  value  is  value  as  a   final  good,  and  use  value  is  value  as  an  intermediate   good.) Does  so&ware  have  greater  use  value  or  sale  value?
4. Manufacturing  Delusion Factory  Model: 1. Most  developer  @me  is  paid  for  by  sale  value. 2. The  sale  value  of  soLware  is  propor@onal  to  its   development  cost  (i.e.,  the  cost  of  the  resources   required  to  func@onally  replicate  it)  and  to  its  use   value. In  other  words,  people  have  a  strong  tendency  to   assume  that  soLware  has  the  value  characteris@cs  of  a   typical  manufactured  good.  Is  this  accurate?
5. On  Maintenance This  is  called  ‘maintenance’,  and  any  soLware  engineer   or  systems  analyst  will  tell  you  that  it  makes  up  the  vast   majority  (more  than  75%)  of  what  programmers  get  paid   to  do.  Accordingly,  most  programmer-­‐hours  are  spent   (and  most  programmer  salaries  are  paid  for)  wri@ng  or   maintaining  in-­‐house  code  that  has  no  sale  value  at  all. In  other  words,  so&ware  is  largely  a  service  industry   opera9ng  under  the  persistent  but  unfounded  delusion   that  it  is  a  manufacturing  industry.
6. So?ware  as  a  Service To  handle  the  real  cost  structure  of  the  soLware  life   cycle  efficiently,  we  require  a  price  structure  founded  on   service  contracts,  subscrip@ons,  and  a  con9nuing   exchange  of  value  between  vendor  and  customer. A  bit  different  than  the  SaaS  of  today,  where  soLware  is   offered  on  demand  from  the  cloud. Thus,  many  proprietary  soLware  sale  prices  are  only   worth  paying  as  claims  on  other  goods:  vendor  support,   or  the  paper  manuals,  or  a  feeling  of  virtuousness.
7. Tragedy  of  the  Commons Imagine  a  green  held  in  common  by  a  village  of   peasants,  who  graze  their  caYle  there.  But  grazing   degrades  the  commons,  tearing  up  grass  and  leaving   muddy  patches,  which  re-­‐grow  their  cover  only  slowly.  If   there  is  no  agreed-­‐upon  (and  enforced!)  policy  to   allocate  grazing  rights  that  prevents  overgrazing,  all   par@es'  incen@ves  push  them  to  run  as  many  caYle  as   quickly  as  possible,  trying  to  extract  maximum  value   before  the  commons  degrades  into  a  sea  of  mud. What  are  the  possible  outcomes?
8. Tragedy  of  the  Commons Three  Possible  Outcomes: 1. A  sea  of  mud. 2. For  some  actor  with  coercive  power  to  enforce  an   alloca@on  policy  on  behalf  of  the  village  (the   communist  solu@on). 3. To  break  up  as  village  members  fence  off  bits  they   can  defend  and  manage  sustainably  (the  property-­‐ rights  solu@on).
9. The  Inverse  Commons Using  soLware  does  not  decrease  its  value.  Indeed,   widespread  use  of  open-­‐source  soLware  tends  to   increase  its  value,  as  users  fold  in  their  own  fixes  and   features  (code  patches).  In  this  inverse  commons,  the   grass  grows  taller  when  it's  grazed  upon. But  why  would  I  choose  to  contribute  in  this   environment  if  I  get  stuff  for  free?
10. Why  Act? Under-­‐provision:  people  don't  merely  need  solu@ons,   they  need  solu@ons  on  @me. Sit  on  the  patch,  or  throw  it  into  the  pool  for  free? On  the  laYer:  This  choice,  apparently  altruis@c,  is   actually  op@mally  selfish  in  a  game-­‐theore@c  sense. The  real  free-­‐rider  problems  in  open-­‐source  soLware   are  more  a  func@on  of  fric@on  costs  in  submibng   patches  than  anything  else.
11. Reasons  for  Closing  Source          1.  To  sell  the  package  to  others                        2.  To  deny  its  use  to  compe@tors When  do  these  points  make  sense  or  not? What  about  in  the  case  of  the  Doom  example  given  in   the  essay?  How  do  network  effects  apply? Also,  knowing  when  to  let  go  of  closed  source  when   sensible.
12. Use-­‐Value  Funding  Models Apache  Case:  Cost  Sharing Op3ons:  Buy  a  proprietary  web  server,  roll  your  own,  join  the   Apache  group Cisco  Case:  Risk-­‐Spreading Modifica3ons  to  the  standard  Unix  print-­‐spooler  soEware,  etc. Cisco  would  have  no  sale  value  to  lose,  and  much  else  to  gain.   By  encouraging  the  growth  of  a  community  of  users  and  co-­‐ developers  spread  across  many  corpora3ons,  Cisco  could   effec3vely  hedge  against  the  loss  of  the  soEware's  original   developers.
13. Problems  with  Sale-­‐Value Symmetry Ability  for  all  par3es  to  profit  equally;  no  one  in  a  privileged  posi3on Unintended  Consequences   E.g.  legal  repercussions Preserving  the  Culture Removing  the  right  to  fork,  for  instance “The  right  to  fork  is  like  the  right  to  strike,  the  right  to  sue,  or  the   right  to  bear  arms—you  don't  want  to  have  to  exercise  any  of  these   rights,  but  it's  a  signal  of  serious  danger  when  anyone  tries  to  take   them  away."
14. Indirect  Sale-­‐Value  Models 5  Known Loss-­‐Leader/Market  Posi3oner Widget  Fros3ng Give  Away  the  Recipe,  Open  a  Restaurant Accessorizing Free  the  Future,  Sell  the  Present 2  Specula@ve Free  the  SoLware,  Sell  the  Brand Free  the  SoLware,  Sell  the  Content
15. Loss-­‐Leader/Market  Posi,oner In  this  model,  you  use  open-­‐source  soLware  to  create  or   maintain  a  market  posi@on  for  proprietary  soLware  that   generates  a  direct  revenue  stream.  In  the  most  common   variant,  open-­‐source  client  soLware  enables  sales  of   server  soLware,  or  subscrip@on/adver@sing  revenue   associated  with  a  portal  site. Adobe  Reader,  Razors,  Subsidized  Phones This  is  what  Netscape  did.  
16. Widget  Fros,ng This  model  is  for  hardware  manufacturers.  Market   pressures  have  forced  hardware  companies  to  write  and   maintain  soLware  (from  device  drivers  through   configura@on  tools  all  the  way  up  to  the  level  of  en@re   opera@ng  systems),  but  the  soLware  itself  is  not  a  profit   center.  It's  an  overhead—oLen  a  substan@al  one.
17. Widget  Fros,ng There's  no  revenue  stream  to  lose,  so  there's  no   downside.  What  the  vendor  gains  is  a  drama@cally  larger   developer  pool,  more  rapid  and  flexible  response  to   customer  needs,  and  beYer  reliability  through  peer   review.  It  gets  ports  to  other  environments  for  free.  It   probably  also  gains  increased  customer  loyalty  as  its   customers'  technical  staffs  put  increasing  amounts  of   @me  into  the  code  to  improve  the  source  as  they   require. Darwin,  Max  OS  X  core
18. Give  Away  the  Recipe,  Open  a   Restaurant In  this  model,  one  open-­‐sources  soLware  to  create  a   market  posi@on  not  for  closed  soLware    but  for  services. Red  Hat:  What  they  are  actually  selling  is  not  the   soLware  but  the  value  added  by  assembling  and  tes@ng   a  running  opera@ng  system  that  is  warranted  to  be   merchantable  and  to  be  plug-­‐compa@ble  with  other   opera@ng  systems  carrying  the  same  brand.  
19. Accessorizing In  this  model,  you  sell  accessories  for  open-­‐source   soLware.  At  the  low  end,  mugs  and  T-­‐shirts;  at  the  high   end,  professionally-­‐edited  and  produced   documenta@on. O'Reilly  &  Associates  Inc.,  publishers  of  many  excellent   reference  volumes  on  open-­‐source  soLware,  is  a  good   example  of  an  accessorizing  company.  O'Reilly  actually   hires  and  supports  well-­‐known  open-­‐source  hackers  as  a   way  of  building  its  reputa@on  in  its  chosen  market.
20. Free  the  Future,  Sell  the  Present In  this  model,  you  release  soLware  in  binaries  and   source  with  a  closed  license,  but  one  that  includes  an   expira@on  date  on  the  closure  provisions.  For  example,   you  might  write  a  license  that  permits  free   redistribu@on,  forbids  commercial  use  without  fee,  and   guarantees  that  the  soLware  come  under  GPL  terms  a   year  aLer  release  or  if  the  vendor  folds.
21. Free  the  So?ware,  Sell  the  Brand You  open-­‐source  a  soLware  technology,  retain  a  test   suite  or  set  of  compa@bility  criteria,  then  sell  users  a   brand  cer@fying  that  their  implementa@on  of  the   technology  is  compa@ble  with  all  others  wearing  the   brand.
22. Free  the  So?ware,  Sell  the  Content Imagine  something  like  a  stock-­‐@cker  subscrip@on   service.  The  value  is  neither  in  the  client  soLware  nor   the  server  but  in  providing  objec@vely  reliable   informa@on.  So  you  open-­‐source  all  the  soLware  and   sell  subscrip@ons  to  the  content.  As  hackers  port  the   client  to  new  plaqorms  and  enhance  it  in  various  ways,   your  market  automa@cally  expands.
23. When  to  Open,  When  to  Close When  the  rent  from  secret  bits  is  higher  than  the  return   from  open  source,  it  makes  economic  sense  to  be   closed-­‐source.   When  the  return  from  open  source  is  higher  than  the   rent  from  secret  bits,  it  makes  sense  to  go  open  source. But  how  exactly  does  one  measure  the  return  from   going  open  source?
24. Discriminators  Towards  Open   Source • Reliability/stability/scalability  are  cri@cal. • Correctness  of  design  and  implementa@on  cannot   readily  be  verified  by  means  other  than  independent   peer  review. • The  soLware  is  cri@cal  to  the  user's  control  of  his/her   business. • The  soLware  establishes  or  enables  a  common   compu@ng  and  communica@ons  infrastructure. • Key  methods  (or  func@onal  equivalents  of  them)  are   part  of  common  engineering  knowledge.
25. Open  Source  as  Strategic  Weapon Cost-­‐Sharing  as  a  Compe@@ve  Weapon Resebng  the  Compe@@on Preven3ng    a  closed-­‐source  alterna3ve  from  geYng  trac3on  in   the  marketplace. Growing  the  Pond Some3mes  the  smartest  way  to  become  a  bigger  frog  is  to   make  the  pond  grow  faster.  Red  Hat  and  RPM  packaging   system. Preven@ng  a  Choke  Hold
26. Open  Source  and  Strategic  Business   Risk Is  using  a  proprietary  vendor  like  pubng  all  your  eggs  in   one  basket? Thoughts  on  this  quote? “When  your  key  business  processes  are  executed  by   opaque  blocks  of  bits  that  you  can't  even  see  inside  (let   alone  modify)  you  have  lost  control  of  your  business.”