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.

Transcript

1. Why Modern Open Source Projects Fail Jailton Coelho, Marco Tulio Valente {jailtoncoelho, mtov}@dcc.ufmg.br ESEC/FSE 2017
2. “Software is eating the world and open source is eating software.” 2
3. Introduction • Most software produced nowadays depend on OSS • OSS are being created at speeds never seen before 64M repositories 3 19M users
4. Why do open source projects fail? 4
5. 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
6. 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
7. Results 7
8. RQ1: Why do open source projects fail? 8
9. Survey Participants • Individual accounts: project owners • Organization accounts: principal contributor 9
10. 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
11. Participation Data • 408 emails sent • 118 answers (response rate of 29%) • 36 answers from the READMEs 11
12. 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
13. 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”.
14. 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”.
15. 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...”.
16. 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
17. 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
18. 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
19. RQ2: What is the importance of following best open source maintenance practices? 19
20. Design • We selected four groups of 104 projects (among top-5k): ◦ Failed ◦ Top ◦ Bottom ◦ Random 20 by stars
21. 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
22. 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)
23. 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)
24. 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)
25. RQ3: What is the impact of the project failures? 25
26. Design • Opened Issues and Pull Requests (104 failed projects) • Over 4,700 opened issues • Around 300 opened pull requests 26
27. Assumption • Negative impact of an abandoned project includes: ◦ bugs and enhancements that will not be considered ◦ pull request that will not be implemented 27
28. Impact of the project failures 28
29. RQ4: How do developers try to overcome the projects failure? 29
30. 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
31. 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
32. 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
33. Take-Away Message • Failed vs Top projects ◦ Contributing guidelines (16% vs 72%) ◦ Continuous integration (27% vs 68%) ◦ License (61% vs 88%) 33
34. Thank you! 34 Jailton Coelho, Marco Tulio Valente {jailtoncoelho, mtov}@dcc.ufmg.br