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

Why Modern Open Source Projects Fail

ASERG, DCC, UFMG
September 06, 2017

Why Modern Open Source Projects Fail

Open source is experiencing a renaissance period, due to the appearance of modern platforms and workflows for developing and maintaining public code. As a result, developers are creating open source software at speeds never seen before. Consequently, these projects are also facing unprecedented mortality rates. To better understand the reasons for the failure of modern open source projects, this paper describes the results of a survey with the maintainers of 104 popular GitHub systems that have been deprecated. We provide a set of nine reasons for the failure of these open source projects. We also show that some maintenance practices—specifically the adoption of contributing guidelines and continuous integration— have an important association with a project failure or success. Finally, we discuss and reveal the principal strategies developers have tried to overcome the failure of the studied projects.

ASERG, DCC, UFMG

September 06, 2017
Tweet

More Decks by ASERG, DCC, UFMG

Other Decks in Research

Transcript

  1. Why Modern Open Source Projects Fail Jailton Coelho, Marco Tulio

    Valente {jailtoncoelho, mtov}@dcc.ufmg.br ESEC/FSE 2017
  2. Introduction • Most software produced nowadays depend on OSS •

    OSS are being created at speeds never seen before 64M repositories 3 19M users
  3. Research Questions • RQ1: Why do open source projects fail?

    • RQ2: What is the importance of open source maintenance practices? • RQ3: What is the impact of project failures? • RQ4: How do developers try to overcome projects failure? 5
  4. Dataset • Top-5,000 GitHub projects by stars • 618 projects:

    ◦ 542 projects without commits in the last year ◦ 76 projects declared as unmaintained in their READMEs 6
  5. Survey Questionnaire • Do you agree that the project is

    unmaintained? • If Yes: a. Why did you stop maintaining the project? b. Did you receive any funding to maintain the project? c. Do you have plans to reactivate the project? 10
  6. Participation Data • 408 emails sent • 118 answers (response

    rate of 29%) • 36 answers from the READMEs 11
  7. Survey Answers • Do you agree that the project is

    unmaintained? ◦ Yes: 86% No: 14% • Do you have plans to reactivate the project? ◦ Yes: 15% No: 85% 12
  8. Why did you stop maintaining the project? • The project

    was usurped by competitor (30 answers) 13 “The project no longer makes sense. Apple has built technical and legal alternatives which I believe are satisfactory”.
  9. Why did you stop maintaining the project? • Lack of

    time of the main contributor (27 answers) 14 “I was the only maintainer and there was a lot of feature requests and I didn't have enough time”.
  10. Why did you stop maintaining the project? • The projects

    is completed (17 answers): ◦ It is stable and works as expected ◦ Do not need changes 15 “Sometimes, you build something, and sometimes, it's completed. Like if you built a building, at some point in time it is finished, it achieved its goals...”.
  11. Combining the Survey Answers • A project has failed when:

    ◦ It is unmaintained ◦ It is not considered completed ◦ Maintainers do not have plans to reactivate • 104 projects that have failed 16
  12. Our Definition of Failure • The project has been abandoned

    (or deprecated) • The project may have been important to developers and users before being deprecated 17
  13. Reason Projects Usurped by competitor 27 Obsolete 20 Lack of

    time 18 Lack of interest 18 Outdated technologies 14 Low maintainability 7 Conflicts among developers 3 Legal problems 2 Acquisition 1 Why do open source projects fail? 18
  14. Design • We selected four groups of 104 projects (among

    top-5k): ◦ Failed ◦ Top ◦ Bottom ◦ Random 20 by stars
  15. Open source maintenance practices 1. README 2. License 3. Home

    Page 4. Continuous Integration 5. Contributing Guidelines 6. Issue Template 7. Code of Conduct 8. Pull Request Template 21
  16. 22 Maintenance Practice Failed(%) Top(%) Bottom(%) Random(%) README 99 100

    100 100 License 61 88 60 73 Home Page 58 87 52 60 Continuous Integration 27 68 41 45 Contributing Guidelines 16 72 13 32 Issue Template 0 15 2 5 Code of Conduct 0 13 0 2 Pull Request Template 0 3 0 0 Fail vs (Top, Bottom, and Random)
  17. 23 Maintenance Practice Failed(%) Top(%) Bottom(%) Random(%) README 99 100

    100 100 License 61 88 60 73 Home Page 58 87 52 60 Continuous Integration 27 68 41 45 Contributing Guidelines 16 72 13 32 Issue Template 0 15 2 5 Code of Conduct 0 13 0 2 Pull Request Template 0 3 0 0 Fail vs (Top, Bottom, and Random)
  18. 24 Maintenance Practice Failed(%) Top(%) Bottom(%) Random(%) README 99 100

    100 100 License 61 88 60 73 Home Page 58 87 52 60 Continuous Integration 27 68 41 45 Contributing Guidelines 16 72 13 32 Issue Template 0 15 2 5 Code of Conduct 0 13 0 2 Pull Request Template 0 3 0 0 Fail vs (Top, Bottom, and Random)
  19. Design • Opened Issues and Pull Requests (104 failed projects)

    • Over 4,700 opened issues • Around 300 opened pull requests 26
  20. Assumption • Negative impact of an abandoned project includes: ◦

    bugs and enhancements that will not be considered ◦ pull request that will not be implemented 27
  21. Design • We manually analyzed over 1,600 issues • In

    32 issues developers discuss about the project’s status • Examples: ◦ Is this project dead? ◦ Is this project maintained? ◦ Is development of this ongoing? 30
  22. How do developers try to overcome the projects failure? •

    Moving to an organization account (5 projects) • Include new core developers (5 projects) • Transfer the project to new maintainers (3 projects) • Owners suggested migrate to another project (19 projects) 31
  23. Take-Away Message • Top-5 most common reasons for the failure

    of OSS: ◦ project was usurped by competitor ◦ project became functionally obsolete ◦ lack of time of the main contributor ◦ lack of interest of the main contributor ◦ project is based on outdated technologies 32
  24. Take-Away Message • Failed vs Top projects ◦ Contributing guidelines

    (16% vs 72%) ◦ Continuous integration (27% vs 68%) ◦ License (61% vs 88%) 33