1) The document discusses how to create and improve open source software (OSS) projects and their communities. It addresses questions around the purpose of the OSS, languages used, versioning, and community engagement. 2) Key recommendations for building community include using English, being open to contributions, demonstrating stability and maintenance, and having a pluggable architecture. 3) The document debates tradeoffs like clean code vs quick contributions, focused vs feature-rich software, and localized vs global development and highlights the need to choose approaches given limitations. Overall it stresses continuous improvement over time.

1. How to Create/Improve
OSS Product and Its Community
(Revised with Beer 🍻)
java-ja.OSS (2015/10/05)
Satoshi Tagomori (@tagomoris)

2. Satoshi "Moris" Tagomori
(@tagomoris)
Fluentd, Norikra, MessagePack-Ruby, Woothee, ...
Docker logging driver for Fluentd (docker v1.8)
Treasure Data, Inc.

3. –tagomoris 🍻
“I never got mails from Tony Morris.”
“Didn't you work about OSS?”

4. We are hiring!

5. DataWe

6. We are hiring!
Skillful Java programmers
(+ Ruby!)
&
Distributed system engineers

7. http://yapcasia.org/2015/talk/show/5f5cad74-004a-11e5-acf4-89c77d574c3a

8. http://t-wada.hatenablog.jp/entry/active-oss-development-vs-simplicity

9. http://tagomoris.hatenablog.com/entry/2015/08/31/101025

10. How to create/improve OSS
product and its community
• What the OSS product is for?
• What programming language the product is written in?
• How do we versioning about the product?
• What (natural) language we use around the product?
• How can we create the community around the product?
• Famous developer people problem
• The way to live as a OSS developer

11. Discussions about OSS
development and maintenance
• Clean code vs dirty contributions
• Software getting fatty vs small/beautiful new product
• All-in-one vs plugin chaos
• Japanese for closed/fast vs English for openness
• Which way we should choose?

12. All OSS products needs:
More users
More use-cases
More contributions

13. 🍻
Except for exceptions :P
ex: PoC, Just for Fun, ...

14. What's the OSS Product For?
• OSS version of internal product?
• OSS native?
• Internal use + alpha?
• Internal use primary, Global use secondary?
• Global use primary, Internal use secondary?
• Global use primary (and nothing else)?

15. What's the OSS Product For?
(2)
• What depends on "What the OSS Product Is For?"
• Core developer selection
• How to accept contribution
• How to maintain that software

16. What's the OSS Product For?
(3)
• Things nice to have to create/improve community
• Open developer team
• Open steps for contribution
• Support from a company

17. What (Natural) Language We
Use Around the Product?
• English! English! English!
• Almost all things around the product should be done in
English:
• Code/Commit comments
• Issues, Pull-requests, Mailing lists
• Software design sheets / its drafts

18. What (Natural) Language We
Use Around the Product?
• What important is to express:
"We DON'T exclude you."
by using English

19. How does spoil using
English our skill?
🍻
It can't be measured
if we use only Enligh :P

20. How Can We Create the
Community around the Product?
• Create/Maintain good software
• Be open for contribution
• Show it's stable and still under maintenance
• Communicate with people all over the world in English

21. How Can We Create the Community
around the Product?
(2)
• One more thing: Pluggable/module architecture
• Apache httpd, Nginx, Linux kernel, ...
• Emacs, Vim, Eclipse, IntelliJ IDEA (and many IDEs), ...
• Plagger, Fluentd, ...
• Pluggable architecture makes user community to be
developer community!

22. The Way to Live
as an OSS developer
• We can't create a super product at first
• Nobody can create a super product without
continuous improvement

23. The Way to Live as an OSS developer
Do it, and keep doing it.

24. pictures of beers or
something else
break...

25. Discussions about OSS
development and maintenance
• Clean code vs dirty contributions
• Software getting fatty vs small/beautiful new product
• All-in-one vs plugin chaos
• Japanese for closed/fast development
vs English for openness
• What should we do?

26. 🍻
Clean code vs dirty contribution
• Bad feature: Say "NO!"
• Good feature:
• Someone said: "OK, I'll write a patch to solve it!"
• Good code: "Great, merged!"
• Bad code: .... 🍻

27. 🍻
Software getting fatty vs
Small/beautiful new product
• Docker vs Rocket
• (Language what you're using) vs Golang
• Recent Hashicorp products vs Past these

28. 🍻
All-in-one vs plugin chaos
• For example: Logstash and Fluentd
• Logstash has many well-organized plugins
• And large developer team
• Well managed plugin portfolio, controlled by someone
• Fluentd only has APIs (and few built-in plugins)
• And very small committer team
• Uncontrolled plugin chaos, contributed by many people

29. 🍻
Japanese for closed/fast development
vs English for openness

30. 🍻
Japanese for closed/fast development
vs English for openness
• "divide and conquer" by using local language
• it's reasonable only if:
• local community has many leading engineers in
the world
• team has enough resource to publish the product
in whole world when it goes global
• IMO, it's not reasonable for many cases

31. What should we do?
Many things make many limitations...

32. 🍻
What should we do?

33. What should we do?
• We have not so many options:
• Limited English? or not-so-limited Japanese?
• Dirty hack? or not-so-beautiful code?
• Local strong closed team and (strong marketing
team + money)? or global weak spreading team?
• We must choose the way to go every time

34. The Way to Live as an OSS developer
Do it, and keep doing it.
(again)