The document discusses best practices for setting up infrastructure to support free and open source software communities. It covers different types of communities that may need support, the various tools and services required for things like version control, continuous integration, and communication. It also discusses challenges around authentication, using external versus internal infrastructure, and ensuring sustainability of community infrastructure over the long term.

1. Free software community
project infrastructure
Michael Scherer, misc@redhat.com

2. Who am I ?

3. Sysadmin @

4. OSAS Team
@ Red Hat

5. Community nurturing

6. Infrastructure setup
and consulting

7. Why infrastructure ?

8. Community tuteur

9. Enable community to
« do stuff »

10. Free software community
project infrastructure

11. Mostly focused on software

12. Wikipedia

13. TuxFamily

14. Free software community
project infrastructure

15. In the open

16. Different types of
community

17. Group of companies ?

18. Single company +
individuals ?

19. Individuals ?

20. NGO ?

21. A mix of this ?

22. Impact on ressources
and needs

23. Free software community
project infrastructure

24. Different size of projects

25. Small ruby module

26. Fork of a linux distribution
like Mageia

27. New language like Rust, Go

28. Impact on tooling

29. Free software community
project infrastructure

30. Personal classification

31. 3 types of infra

32. Production focused

33. VCS ( git, hg, svn, etc)

34. Continous integration

35. Jenkins, travis, buildbot, etc

36. Bugtracker

37. Bugzilla, jira, etc

38. CDN / Mirrors

39. Documentation ?

40. Translation ?

41. QA ?

42. Specific tooling

43. Security update

44. Build systems

45. Package/binary
signing

46. Infrastructure focused

47. Monitoring

48. Backups

49. Configuration management

50. Communication focused

51. Internal

52. Mailling lists

53. IRC

54. External

55. Website

56. Social media

57. Best practices

58. Si fueris Romae, Romano
vivito more ; si fueris
alibi vivito sicut ibi

59. Follow the rest of the
ecosystem

60. Java projects on jira ?

61. Python go to bitbucket and
mercurial

62. Etc, etc

63. Ease recruiting project
members

64. Tooling around the default
location

65. More is not better

66. IRC + XMPP + Forum + ML
+ Usenet + etc

67. Too much choice

68. Requires ressources

69. Sysadmin ressources

70. Communication ressources

71. Make communication harder

72. Harder to communicate
culture

73. ... especially when the
current hot topic is
inclusiveness

74. What type of
communication ?

75. « Customer services »

76. Project work related topic

77. General community chat

78. Differents needs

79. Latency expectation

80. Formatting ?

81. Need for moderation and
archiving

82. Ressources needed

83. Technical level to use

84. Unspoken assumptions and
conventions

85. Authentication and
workflow to communicate

86. Authentication

87. Elephant in the room

88. Major source of confusion
@mandriva

89. People forget their password

90. People forget their login

91. No way to track users among
the whole project

92. No global view of
permissions

93. Difficulty to give vanity
email domain

94. Few solutions

95. No central auth

96. Easy...

97. But messy...

98. Reusing external auth

99. Github, Twitter, Openid,
Persona

100. Only solve authentication,
not authorization

101. What about non web auth ?

102. Jenkins, Git, etc

103. What about mandating 2
FA ?

104. LDAP

105. Or similar

106. More complex

107. Not always supported

108. Not supported in the same
way everywhere

109. Requires web interface to
manage accounts

110. Hard to get right

111. FreeIPA

112. FedAuth

113. LDAP + OpenID + Persona

114. Use external or internal
infra ?

115. Use external

116. Pros

117. Easier to start

118. Permit to outsource
maintainance

119. Improve by itself

120. Cons

121. Often proprietary

122. Not always flexible enough

123. Can be closed

124. Can « improve » in way we
do not want

125. Can become a paid offer

126. Can be blocked in some
country

127. ( ask my boss in China about
AWS )

128. Use internal infrastructure

129. Pro

130. Full flexibility...

131. ..if you have enough
sustained ressources

132. Integration with any auth

133. Independant from provider

134. Cons

135. Requires people

136. Requires money/server

137. Hybrid approach

138. Use github and your own
bugtracker

139. ( private security bug on git
hub issues ? )

140. Going on self hosted

141. o/ Yeah o/

142. Finding material
ressources

143. Money from companies

144. Sponsorship from Cloud
offering

145. Rackspace

146. Google

147. OVH

148. Lost Oasis

149. Ikoula

150. Microsoft Azure

151. Kickstarter, patreon, etc

152. HP, Dell, IBM, etc

153. University hosting ?

154. Geeks working at hosting
companies

155. Growing a community of
admins

156. Quite hard

157. Need a full time person most
of the time

158. Set of best practices

159. Clear contact informations

160. Always aim to grow it

161. Bus factor > 2 or 3

162. Automate as much as
possible

163. Usage of configuration
management

164. Only sane way to work in a
team as admin

165. Requires some knowledge
from community

166. Work in the open

167. Publish configuration

168. Except passwords

169. Warn about planned
downtime

170. Publish postmortem

171. Try to make regular reviews

172. Can double as learning for
newer team members

173. Write documentation

174. Fedora SOP

175. Communicate a lot internally

176. Going on holiday ?

177. People on-call ?

178. Delegate as much as
possible

179. Self service
approval process

180. Reduce bureaucracy

181. Do not write your own
software

182. Do say « no »

183. ?