Free Software development through shared governance
I first joined Linagora because I was eager to be involved into Free Software development — and had never had.
Free Software development can simply be defined as a software that we are free to:
— Read its source code
— Modify its source code
— Use and execute the source code or its modified version
— Share it or its modifications
Basically these rights are enforced through the use of Free Licenses like the GPL one.
However, the “legal aspect” of Free Software was clearly not what motivated me the most. I could write, alone, my own project, and publish it with a license. That would technically be Free Software, but the “soul” of it would be lacking.
I was looking for contributing useful changes to a well-known project with a large user base. I was looking for interactions and knowledge sharing from experts throughout the world. I was looking for mentorship and guidance.
One could argue that “Free Software” as defined before leads to “the freedom to work on your side, alone”. Without further ingredients it leads to forks, frustration, and isolation. And isolation might harm overall project viability.
Interesting… What ingredients could it be?
In my opinion it is shared governance:
— Project members can debate, exchange ideas, in a safe and welcoming environment.
— Decision are taken by the whole community, looking for consensus.
Shared governance in practice
This shared governance is in the DNA of the Apache foundation. It also is one of the key James team concerns at Linagora. We thus came with a list of actions to re-enforce this shared governance in the Apache James project.
— We need to clearly expose our goals: why do we contribute, what are our objectives, what means are we willing to dedicate to the achievement of these goals, etc.
— We expose what we do: We create detailed tickets with enough technical details early, we handle publicly available pull requests, referenced from the tickets.
— We expose what we will do: We explain features we contribute, and why they would benefit the community.
— We give a place for the community to exchange: Mailing lists are critical for Apache projects. Linagora also bootstrapped a Gitter live chat.
— We enforce vote and aim for consensus: this is a key rule for the Apache foundation
— Adopting a flexible enough plugin architecture. Having a customizable solution also lowers the friction between community members.
Cool! We have the framework to interact with people… But… Something is missing to the picture! Peoples…
Attracting new contributors
Because shared governance can not be done alone, because lives of people often change, we need to constantly attract contributors.
A core concern we, of course, debated…
— We lowered the on-boarding coast: Using Git, exposing the project on GitHub. We built a Jenkins CI already set up for James. We updated loads of documentation and tutorials.
— We eased the contribution workflow: We use common processes via GitHub, we offer builds on contributor pull requests using our CI (Continuous Integration, via Jenkins).
— We refreshed the website: With also some great contribution from LinDa
— We release often: Because people are eager to use the awesome stuff we work on, we ship a new James version alongside the OpenPaaS releases every 3–4 months.
— We create easy to handle, welcoming newbie tickets for which we provide reviews, resources and guidance. Through such tickets, the community completed the “health check” feature as part of the 2018 HacktoberFest.
— We sadly can not make all the features we implement for all James products. However we constantly keep track of these missing bits of implementation through tickets.
— We organized ourselves, with dedicated rotating roles to deliver quick answers and feed-backs to the community.
Of course, the above list might be partial, and we are more than welcome for suggestion of addition!
To conclude, I am very happy that I contributed to set up what I was initially looking for. I am really interested to see the results of these huge ongoing efforts.
The author, Benoit Tellier works for 5 years at Linagora, and is devoted to the Apache James project. As a reward of the intense involvement of Linagora employees in the Apache James community, he had recently been promoted as Apache James project chairman. This is a concrete recognition of Linagora Free Software development involvement and expertise.
Apache James is the email server used by Linagora as part of the OpenPaaS product.
Linagora contributors desire to build a distributed, scalable mail server, targeting deployments of hundreds of thousands users, without the need of classic sharding technics. We want this mail server to be easily customizable. Our efforts are mostly directed towards an MDA (Mail Delivery Agent) platform based on the JMAP protocol.
We also consider it important to maintain a product targeting smaller deployments leveraging the IMAP and SMTP protocols.
