Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
Prochain SlideShare
Open Source for Products in Four Rules (or Ten Slides)
Suivant
Télécharger pour lire hors ligne et voir en mode plein écran

Partager

Scale14x Patterns and Practices for Open Source Project Success

Télécharger pour lire hors ligne

There are two parts to the “success” of an open source software project:

Deployment growth: One publishes software to see it used. As the software is used, it reflects the dynamic nature of software, and is used in new ways to solve new problems. This leads to the second part of the success formula -- contributions.

Contribution flow: A free or open source software project is at it’s simplest a discussion in software, and without contributions the conversation fades and fails. From a more complex community perspective, a FOSS project is about the economics of collaborative innovation and development. Without a continuous contribution flow, the dynamic aspect of a software project will become static and brittle and lose its relevancy.

There are three on ramps to be built to drive the success of an open source project: Bringing new users to the project, enabling developers, and encouraging contributors. This talk looks at how these on ramps can be organized to drive growth and adoption, and to grow a successful and vibrant community around an open source project.

The talk was delivered at SCaLE 14x: https://www.socallinuxexpo.org/scale/14x/presentations/patterns-and-practices-open-source-project-success

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir

Scale14x Patterns and Practices for Open Source Project Success

  1. 1. Patterns  and  Practices  for   Open  Source  Project  Success stephen r.  walli @stephenrwalli stephen.walli@gmail.com
  2. 2. Freeloaders  are  Necessary stephen r.  walli @stephenrwalli stephen.walli@gmail.com
  3. 3. WTFOSS* stephen r.  walli @stephenrwalli stephen.walli@gmail.com *  Hat  tip  to  @codepope
  4. 4. Community
  5. 5. We’ve  shared  software  since  we’ve  written  software Writing  good  software  is  hard  work Princeton USENIX SHARE DECUS MIT  Athena Free  Software   FountationBerkeley  CSRG Apache Linux Eclipse Fountation ASF
  6. 6. 2  Stories
  7. 7. Orders of magnitude
  8. 8. ROTOR 500K  LoC 500K  Lines-­‐of-­‐Test  Harness Ran  on  Windows,  Mac  OS  X,  FreeBSD One  script  to  set  environment One  command  to  build  everything One  command  to  test  it  all Minimal  documentation 24  hours  later  … 24  hours  later  again  …  
  9. 9. Committer(s) + Code
  10. 10. Developers Committers + Code
  11. 11. Developers Committers + Code
  12. 12. Developers Users Committers + Code
  13. 13. Developers Users Committers + Code
  14. 14. How  do  you  increase  your  user  base? (How  do  you  make  it  easy  to  install/configure/use  the  software?) How  do  you  encourage  developers? (How  do  you  make  it  easy  to  build/test/experiment?) How  do  you  make  it  easy  to  contribute? (What  do  you  communicate  to  your  community)
  15. 15. How  do  you  increase  your  user  base? (How  do  you  make  it  easy  to  install/configure/use  the  software?)
  16. 16. How  do  you  increase  your  user  base? (How  do  you  make  it  easy  to  install/configure/use  the  software?) Project  Exes   published Project  Install   Automated Software  Construction  Activities Project   BugTracking
  17. 17. How  do  you  increase  your  user  base? (How  do  you  make  it  easy  to  install/configure/use  the  software?) Project  Exes   published Project  Install   Automated Software  Construction  Activities Project   License FAQs,  Howto Community  Development  Activities   Project   BugTrackingForums,  Email
  18. 18. IANAL
  19. 19. A  small  (2  minute)  diversion  on  licensing  …. • Software  is  protected  by  copyright  law   • Whoever  wrote  the  software,  owns  the  copyright • People  often  give  up  copyright  ownership  in  employment  agreements • There  are  a  few  well  [understood|accepted]  licenses:  pick  one • These  licenses  define  the  most  successful  collaborations  in  history • If  you  care  about  making  money:  educate  yourself*  &  hire  a  lawyer • If  you  [care|worry]  about  patents:  hire  a  lawyer • If  you  publish  your  project  on  Github: create  the  *%$ing LICENSE  file Writers|Artists|Engineers|Architectsdo  it.  So  should  you. *Van  Lindberg's Intellectual  Property  and  Open  Source
  20. 20. How  do  you  encourage  developers? (How  do  you  make  it  easy  to  build/test/experiment?)
  21. 21. How  do  you  encourage  developers? (How  do  you  make  it  easy  to  build/test/experiment?) Project  Build   Automated  I Complete  Src published Project  Test   Automated  I Software  Construction  Activities
  22. 22. How  do  you  encourage  developers? (How  do  you  make  it  easy  to  build/test/experiment?) Project  Build   Automated  I Complete  Src published Project  Test   Automated  I Software  Construction  Activities Mission Statement Comms Platform Contributoion Guidelines Community  Development  Activities   Code  of   Conduct
  23. 23. A  small  diversion  on  software  engineering  … • 2  ratios  define  software  development • All  advances  in  programming  languages  and  software   engineering  is  attempting  to  beat  these  two  ratios • [Community|Product]  scale  depends  on  reliably  delivering   the  known  executable  environment  every  time   • Linus’s  Law  is  about  REVIEWS  not  BUG  FIXING
  24. 24. How  do  you  make  it  easy  to  contribute? (What  do  you  communicate  to  your  community)
  25. 25. How  do  you  make  it  easy  to  contribute? (What  do  you  communicate  to  your  community) Project  Build   Automated  II Project  Test   Automated  II Basic  Arch   Description Software  Construction  Activities
  26. 26. How  do  you  make  it  easy  to  contribute? (What  do  you  communicate  to  your  community) Project  Build   Automated  II Project  Test   Automated  II Basic  Arch   Description Software  Construction  Activities Governance Events Community  Development  Activities  
  27. 27. Committers Contributors Community EcosystemProject Products Services Books Training
  28. 28. Committers Contributors Community EcosystemProject Products Services Books Training Corporate Contributors
  29. 29. How  do  you  make  it  easy  to  contribute? (What  do  you  communicate  to  your  COMMERCIAL  community) Project   License Provenance   Tracking Repositories   Protected Dependencies   Documented Contributions   Auditted Provenance   Management Committers Indemnified Committer   Governance Trademark   Management IP  Management  Activities  
  30. 30. Foundations • Henrik  Ingo’s  numbers • Foundations  provide  neutral  ownership  and  a  level  playing  field • Bright  lines  for  projects  versus  products
  31. 31. Open  Source  Community  Practices Project  Exes   published Project  Build   Automated  I Project  Install   Automated Complete  Src published Project   BugTracking Project  Build   Automated  II Project  Test   Automated  I Project  Test   Automated  II Basic  Arch   Description Project   License Project   License Mission Statement Code  of   Conduct Forums,  Email Comms Platform FAQs,  Howto Governance Contributoion Guidelines Events Provenance   Tracking Repositories   Protected Dependencies   Documented Contributions   Auditted Provenance   Management Committers Indemnified Committer   Governance Trademark   Management IP  Management  Activities   Community  Development   Software  Construction  Maturity
  32. 32. Open  Source  Community  Patterns Project  Exes   published Project  Build   Automated  I Project  Install   Automated Complete  Src published Project   BugTracking Project  Build   Automated  II Project  Test   Automated  I Project  Test   Automated  II Basic  Arch   Description Project   License Project   License Mission Statement Code  of   Conduct Forums,  Email Comms Platform FAQs,  Howto Governance Contributoion Guidelines Events Provenance   Tracking Repositories   Protected Dependencies   Documented Contributions   Auditted Provenance   Management Committers Indemnified Committer   Governance Trademark   Management IP  Management  Activities   Community  Development   Software  Construction  Maturity Encourage Users Encourage ContributorsEncourage  Developers Encourage  Corp   Contributions
  33. 33. Developers Users Committers + Code
  34. 34. Developers Users Committers + Code Books Contractors Products Distributions Consulting Training Support Building  the  Ecosystem
  35. 35. Committers Contributors Community EcosystemProject Products Services Books Training Corporate Contributors Customers
  36. 36. Committers Contributors Community EcosystemProject Products Services Books Training Corporate Contributors Customers
  37. 37. Questions  &  Comments stephen r walli stephen.walli@gmail.com @stephenrwalli http://stephesblog.blogs.com http://opensource.com
  • tselrahc

    May. 11, 2017

There are two parts to the “success” of an open source software project: Deployment growth: One publishes software to see it used. As the software is used, it reflects the dynamic nature of software, and is used in new ways to solve new problems. This leads to the second part of the success formula -- contributions. Contribution flow: A free or open source software project is at it’s simplest a discussion in software, and without contributions the conversation fades and fails. From a more complex community perspective, a FOSS project is about the economics of collaborative innovation and development. Without a continuous contribution flow, the dynamic aspect of a software project will become static and brittle and lose its relevancy. There are three on ramps to be built to drive the success of an open source project: Bringing new users to the project, enabling developers, and encouraging contributors. This talk looks at how these on ramps can be organized to drive growth and adoption, and to grow a successful and vibrant community around an open source project. The talk was delivered at SCaLE 14x: https://www.socallinuxexpo.org/scale/14x/presentations/patterns-and-practices-open-source-project-success

Vues

Nombre de vues

1 615

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

54

Actions

Téléchargements

9

Partages

0

Commentaires

0

Mentions J'aime

1

×