Running an independent open source project by example

Almost exactly 10 years ago, I had the first discussions about how to keep evolving JUnit at conferences. I had been a maintainer for JUnit for 2 years and recently been promoted to ”keeper of the green bar,“ i.e., project/team lead of the project. While being a wildly popular testing framework, maintaining JUnit was challenging due to IDEs, build tools, and third-party extensions relying on implementation details. Plus, I felt I never had enough time to even work through my GitHub notifications.

As I shared these frustrations with fellow developers at conferences, the idea arose to start a crowdfunding campaign to have actual dedicated time to solve the underlying issues. The campaign launched a few months later and came to a successful conclusion in September 2015. We formed a team, had a kickoff with relevant stakeholders (IDEs, build tools, …), and set to work. Finally, six weeks of time to work on JUnit! As you can imagine, that time passed relatively quickly and the project was far from finished. Despite that we eventually released JUnit 5.0 in September 2017. But development didn’t stop there and has kept going since. In this talk, I will share insights about the most important factors for keeping the project running successfully.

Transcript

1. Running an independent open source project by example JavaZone 2024, Oslo
2. Marc Philipp
3. JUnit in a nutshell • • • • •
4. Agenda
5. Disclaimer • • •
6. Show of hands
7. Brief project history
8. Becoming a JUnit 4 maintainer (2010-2012) • • ▪ • •
9. JUnit 4 architecture
10. Coupling with IDEs
11. Issues with JUnit 4 (2012-2014) • • •
12. Idea: Let’s modernize JUnit (2014)
13. Crowdfunding (2015)
14. Crowdfunding (2015) • •
15. Kickoff (2015) • •
16. Kickoff decisions (2015) • • • •
17. The first six weeks (2015) • • •
18. The road to GA (2016-2017)
19. JUnit 5 feature releases (2018-today)
20. Sponsors (2019-today) • ▪ ▪ • •
21. Thank you to our sponsors!
22. Adoption (2024)
23. Adoption (2024) • ▪ ▪ ▪ ▪ • •
24. Lessons learned (technical)
25. backward compatibility • •
26. build features via extension points • • •
27. mark new features as “experimental” in initial release • @API(status) •
28. automate updates of build and project dependencies • • •
29. have useful CI builds • • • •
30. enforce code formatting in the build • •
31. automate checking of architecture principles • • @API •
32. keep the build fast and free of deprecations • • •
33. Lessons learned (people)
34. building a relationship with stakeholders is important • •
35. conflicts will happen • •
36. dealing with toxicity • • • •
37. weekly team calls help keep momentum • • •
38. in-person meetings are fun and useful
39. grow the team • • •
40. Lessons learned (project management)
41. no one will test an alpha release
42. small, manageable, interesting tasks • •
43. auto-closing issues is a mixed blessing • •
44. embrace contributions but know when to take over • •
45. check definition of done for PRs • • •
46. Then vs. now
47. Status of JUnit in 2014 • • •
48. Status of JUnit in 2024 • • • •
49. …and…
50. The Sovereign Tech Fund will invest in JUnit in 2024 and 2025!
51. Sovereign Tech Fund • • •
52. Full-time work on JUnit (2024-2025) • • • • • • • •
53. Things are looking up!
54. Key takeaways • • •
55. Q & A
56. Thanks!