Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Class 5: Software Licenses and Development Philosophies

Class 5: Software Licenses and Development Philosophies

Notes for 6/6/2013

Ian Luke Kane

June 06, 2013
Tweet

More Decks by Ian Luke Kane

Other Decks in Technology

Transcript

  1. So#ware  Licenses A  legal  instrument  governing  the  use  or  redistribu3on

     of   so5ware. Roughly  split  between  proprietary  and  open  source   (“free”)  licenses. The  end-­‐user  license  agreement  (EULA) 2
  2. iTunes  EULA,  for  example Check  it  out Related:  Richard  Dreyfuss

     reads  the  iTunes  EULA E.  YOU  FURTHER  ACKNOWLEDGE  THAT  THE  APPLE  SOFTWARE  AND  SERVICES  ARE   NOT  INTENDED  OR  SUITABLE  FOR  USE  IN  SITUATIONS  OR  ENVIRONMENTS  WHERE  THE   FAILURE  OR  TIME  DELAYS  OF,  OR  ERRORS  OR  INACCURACIES  IN,  THE  CONTENT,  DATA   OR  INFORMATION  PROVIDED  BY  THE  APPLE  SOFTWARE  OR  SERVICES  COULD  LEAD  TO   DEATH,  PERSONAL  INJURY,  OR  SEVERE  PHYSICAL  OR  ENVIRONMENTAL  DAMAGE,   INCLUDING  WITHOUT  LIMITATION  THE  OPERATION  OF  NUCLEAR  FACILITIES,  AIRCRAFT   NAVIGATION  OR  COMMUNICATION  SYSTEMS,  AIR  TRAFFIC  CONTROL,  LIFE  SUPPORT  OR   WEAPONS  SYSTEMS. 4
  3. Open  Source  Licenses Split  between  permissive  licenses  and  copyle.  licenses.

    Permissive:  Aim  to  have  minimal  requirements  about   how  they  so5ware  can  be  redistributed  (BSD  and  MIT) Copyle.:  Aim  to  preserve  the  freedoms  give  to  the  users   by  ensuring  that  all  subsequent  users  receive  those   rights  (GPL) Why  so  many  licenses?  Because  there  are  different   goals. 5
  4. Open  Source  License  Primers Jeff  Atwood’s   “Pick  a  License,

     Any  License” Cameron  Chapman’s   “A  Short  Guide  To  Open-­‐Source  and  Similar  Licenses” David  Lee  Todd’s   “Free  and  Open  Source  License  Comparison” GNU’s   “Various  Licenses  and  Comments  about  Them” 6
  5. Open  Source  License  Philosophy Copyright  and  the  21st  Century Tivoiza3on

    Mixing  Code  with  Different  Licenses Patent  Disputes  (Apple  v.  Samsung) Examples: GPL:  Linux LGPL:  7-­‐Zip MIT:  jQuery BSD:  Django  (used  by  Pinterest,  Instagram) Apache:  Hadoop 7
  6. So#ware  Development   Methodologies  and  SDLC A  la  Wikipedia:  A

     framework  that  is  used  to  structure,   plan,  and  control  the  process  of  developing  an   informa8on  system. Different  systems  have  their  own  strengths  and   weaknesses  and  may  be  appropriate  for  a  certain  kind  of   project. They  can  really  be  considered  differing  philosophies. 8
  7. PredicJve  vs.  AdapJve  Spectrum Predic3ve Focus  on  planning  the  future

     in  great  detail  while   aeemp3ng  to  take  known  risks  into  considera3on. Adap3ve Focus  on  being  able  to  adapt  quickly  to  changing   reali3es.  If  the  need  changes,  the  team  changes  as   well.  The  future  is  much  more  fuzzy. The  “Agile”  so5ware  development  methods 9
  8. Waterfall  Development Project  is  divided  into  sequen3al  phases  with  various

      overlaps  and  some  cycling  between  phases Emphasis  on  planning,  scheduling,  hihng  a  date,   budge3ng,  and  implemen3ng  an  en3re  system  at  once. Tightly  controlled  through  documenta3on,  formal   reviews,  and  management  signoff  between  phases.
  9. Scrum  Framework  in  30  Seconds A  product  owner  creates  a

     priori3zed  wish  list  called  a  product   backlog. During  sprint  planning,  the  team  pulls  a  small  chunk  from  the  top  of   that  wishlist,  a  sprint  backlog,  and  decides  how  to  implement  those   pieces. The  team  has  a  certain  amount  of  3me,  a  sprint,  to  complete  its  work  -­‐   usually  two  to  four  weeks  -­‐  but  meets  each  day  to  assess  its  progress   (daily  scrum). Along  the  way,  the  ScrumMaster  keeps  the  team  focused  on  its  goal. At  the  end  of  the  sprint,  the  work  should  be  poten<ally  shippable,  as   in  ready  to  hand  to  a  customer,  put  on  a  store  shelf,  or  show  to  a   stakeholder. The  sprint  ends  with  a  sprint  review  and  retrospec<ve. As  the  next  sprint  begins,  the  team  chooses  another  chunk  of  the  
  10. Asshole  Driven  Development Asshole  Driven  development  (ADD)  –  Any  team

     where   the  biggest  jerk  makes  all  the  big  decisions  is  asshole   driven  development.  All  wisdom,  logic  or  process  goes   out  the  window  when  Mr.  Asshole  is  in  the  room,   doing  whatever  idio3c,  selfish  thing  he  thinks  is  best.   There  may  rules  and  processes,  but  Mr.  A  breaks  them   and  people  follow  anyway. Hilariously  true  ar3cle  by  Scoe  Berkun