OWF14 - Project & Community Driving : Community management of a free software project...

Preview:

DESCRIPTION

Michael SCHERER La production logicielle est un métier très spécialisé, qui requiert une infrastructure parfois spécifique, parfois standard. Et le logiciel libre, de part sa nature transparente et communautaire apporte son lot de contraintes et de bonnes pratiques à suivre pour que la communauté puisse grandir et être productive. Du projet unipersonnel sans infrastructure en propre à une communauté de plus grandes envergure ayant ses propres serveurs, il existe des tas de façons de faire, et nous verrons comment commencer sans se retrouver bloquer, et comment faire grandir l'infrastructure du projet de façon ouverte et le rendre indépendant et résilient, en permettant à la communauté de prendre une part active dans sa gestion.

Citation preview

Free software communityproject infrastructure

Michael Scherer, misc@redhat.com

Who am I ?

Sysadmin @

OSAS Team@ Red Hat

Community nurturing

Infrastructure setup and consulting

Why infrastructure ?

Community tuteur

Enable community to « do stuff »

Free software communityproject infrastructure

Mostly focused on software

Wikipedia

TuxFamily

Free software communityproject infrastructure

In the open

Different types of community

Group of companies ?

Single company + individuals ?

Individuals ?

NGO ?

A mix of this ?

Impact on ressources and needs

Free software communityproject infrastructure

Different size of projects

Small ruby module

Fork of a linux distribution like Mageia

New language like Rust, Go

Impact on tooling

Free software communityproject infrastructure

Personal classification

3 types of infra

Production focused

VCS ( git, hg, svn, etc)

Continous integration

Jenkins, travis, buildbot, etc

Bugtracker

Bugzilla, jira, etc

CDN / Mirrors

Documentation ?

Translation ?

QA ?

Specific tooling

Security update

Build systems

Package/binary signing

Infrastructure focused

Monitoring

Backups

Configuration management

Communication focused

Internal

Mailling lists

IRC

External

Website

Social media

Best practices

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

Follow the rest of the ecosystem

Java projects on jira ?

Python go to bitbucket and mercurial

Etc, etc

Ease recruiting project members

Tooling around the default location

More is not better

IRC + XMPP + Forum + ML + Usenet + etc

Too much choice

Requires ressources

Sysadmin ressources

Communication ressources

Make communication harder

Harder to communicate culture

... especially when the current hot topic is

inclusiveness

What type of communication ?

« Customer services »

Project work related topic

General community chat

Differents needs

Latency expectation

Formatting ?

Need for moderation and archiving

Ressources needed

Technical level to use

Unspoken assumptions and conventions

Authentication and workflow to communicate

Authentication

Elephant in the room

Major source of confusion @mandriva

People forget their password

People forget their login

No way to track users among the whole project

No global view of permissions

Difficulty to give vanity email domain

Few solutions

No central auth

Easy...

But messy...

Reusing external auth

Github, Twitter, Openid, Persona

Only solve authentication, not authorization

What about non web auth ?

Jenkins, Git, etc

What about mandating 2 FA ?

LDAP

Or similar

More complex

Not always supported

Not supported in the same way everywhere

Requires web interface to manage accounts

Hard to get right

FreeIPA

FedAuth

LDAP + OpenID + Persona

Use external or internal infra ?

Use external

Pros

Easier to start

Permit to outsource maintainance

Improve by itself

Cons

Often proprietary

Not always flexible enough

Can be closed

Can « improve » in way we do not want

Can become a paid offer

Can be blocked in some country

( ask my boss in China about AWS )

Use internal infrastructure

Pro

Full flexibility...

..if you have enough sustained ressources

Integration with any auth

Independant from provider

Cons

Requires people

Requires money/server

Hybrid approach

Use github and your own bugtracker

( private security bug on git hub issues ? )

Going on self hosted

\o/ Yeah \o/

Finding material ressources

Money from companies

Sponsorship from Cloud offering

Rackspace

Google

OVH

Lost Oasis

Ikoula

Microsoft Azure

Kickstarter, patreon, etc

HP, Dell, IBM, etc

University hosting ?

Geeks working at hosting companies

Growing a community of admins

Quite hard

Need a full time person most of the time

Set of best practices

Clear contact informations

Always aim to grow it

Bus factor > 2 or 3

Automate as much as possible

Usage of configuration management

Only sane way to work in a team as admin

Requires some knowledge from community

Work in the open

Publish configuration

Except passwords

Warn about planned downtime

Publish postmortem

Try to make regular reviews

Can double as learning for newer team members

Write documentation

Fedora SOP

Communicate a lot internally

Going on holiday ?

People on-call ?

Delegate as much as possible

Self service approval process

Reduce bureaucracy

Do not write your ownsoftware

Do say « no »

?

Recommended