Considerations about human and technological factors, learned on the field while creating, supporting and handling the community of the Redis database project.

1. Running Redis for 8 years
Salvatore Sanfilippo
CODEMOTION MILAN - SPECIAL EDITION
10 – 11 NOVEMBER 2017

2. If you build, they
will come…

3. Two months later

4. If you build, they
will come…

5. Opportunistic
programming

6. Low hanging fruit
triangle

7. RDB replication metadata
• Technological LHF
• Slaves upgrades without a full resynchronization
• Quite simple to implement (because of PSYNC2)
• Hint: certain other features are “enablers” for LHF

8. The issue of issues

9. The issue of issues

10. GitHub issues
• Big projects are a small % of the user base
• Better discovery is needed
• Issues voting is needed
• Users should be able to add labels

11. Slow code

12. Slow code

13. Slow code

14. Slow code
• Design work is silent
• The goal is writing less code, not more
• Tons of throw away experiments, users will see only the good ones
• Understanding what comes next

15. Haters

16. Haters tips
• Reply with love, or you’ll feel like shit as well
• Many haters have (not so well) hidden reasons
• Develop a thick skin…

17. Haters are useful

18. 5% rule
No micro
benchmarks!
Command
calls

19. 5% rule

20. Fuzz testing
is powerful

21. Possible states
VS
lines of code

22. Fuzz testing
radix tree edition
Image courtesy of Vaidehi Joshi
http://medium.com/basecs

23. Fuzz testing
+ comparison
Implementation
Alternative
implementation

24. Backward
compatibility

25. Giving credits

26. Credits
• Publish a change log with names at every release
• Tweet about contributors accomplishment
• Invent symbolic prices to give to the best contribs

27. Failures bias

28. A system is the sum of the behavior
it has during failures and during
normal operations

29. Thanks
Ask me anything if you wish!