PrestaShop is an Open Source project. To most, this mostly means that the software is free of charge: you do not have to pay anyone for the default product. There is much more to this, starting with its community.

This article aims at being a general description of what makes an Open Source community, all the while describing how we envision PrestaShop’s own community. We hope this will lead more people to become Open Source contributor, and why not, contribute to PrestaShop too!

What is an Open Source community?

An Open Source community comprises all the trusted people who are actively working, together and in an open way, at the improvement and promotion of the project, in all its aspects. This defines all contributors, paid or not:

  • developers and designers
  • users
  • distributors : editors, agencies, freelancers, etc.
  • translators
  • participants to the communication channels.

The community initially forms because the project it supports has been released under an Open Source license – which means that its creator/editor allows anyone to use, study, modify and distribute the project, for any purpose, within the constraints of the chosen license.
In that, there is a difference between the Open Source movement and the Free Software movement: if the two are generally speaking of the same approach to software distribution, they do not share the same spirit nor the same licenses. One is more open to commercialization, while the other is all about freedom (hence the saying “Think free as in free speech, not free beer”); some licenses are too restrictive to one party, too open to the other (yes, I am being over-simplistic here). This is all a never-ending philosophical debate, and we won’t dive much into that difference here.

What matters to us is that the license, by its sole existence, allows the community to exist. For one of the main interests of having an Open Source license tied to a project is to allow users to improve the project, by spotting bugs, reporting issues and suggesting code changes. Here we can restate Linus’s Law: “given enough eyeballs, all bugs are shallow”. Having a community is therefore the very essence of an Open Source project, starting with contributing developers and “power users” (those technical enough to know how to write a useful bug report, for instance).
By definition, “closed” projects (the ones without an Open Source license) cannot enjoy such a community: all users depend on the decision of the editor, which can sometimes be arbitrary, without asking for user feedback.

To allow all this to exist, an Open Source project must provide its source code to all, and a couple of basic communication channels: first and foremost, a place here the community can interact with the creator/editor with ideas and issues; and at best, a place where the community can easily and directly change/fix the code – or at the very least, suggest such modifications, which are then either accepted or rejected by the trusted developers). This means the availability of a set of tools (blog, forum, mailing-list, versioning system, etc.), which can even by installed and managed by the community as and when needed.

What is the benefit of having an Open Source community?

The main benefit is tied to the license: enjoy a stream of contributions from volunteers and enthusiast, who all try to fix and improve the project for their own needs – or that of their clients.

First, there will be pioneers: those first users, and the curious developers. Then the community just grows gradually, as its popularity does. At the same time, diversification happens: the profile of community members expand to more than fearless pioneers as more regular users enter the frame. The tasks needed to grow the project diversify too: translation of the software and its documentation, forum moderation and local events, themes and plugin creation, training, accessibility tests… and managing the community itself, on both local and global scales.

Thus a virtuous circle is made: the more a project is used/popular, the more contributors willing to help improve the project (whether for-pay or gratis)… which will in turn get the project more used/popular, if only by word of mouth. The project creator thus gathers an array of talent which are willing to give their time and knowledge for the benefit of all, thus boosting the project’s stability and feature-completeness.

How is an Open Source community created?

The project’s community creates spontaneously, from the moment it is publicly distributed. There still need to be a discussion hub about the project, typically a blog for announcements, an online forum for community support, a chat tool (IRC, Slack, etc.) and/or a mailing-list. As the now-expression goes, “if you build it, they will come” – if only out of curiosity at first.

How to sustain it? How to make it thrive?

I see 5 tools to reach the goal of a healthy community: communication, “do-o-cracy”, interaction, technology, and fun!

Communication

An Open Soure project implies openness and honesty. A software editor can chose to open its codebase, and accompany it with explicit intentions: a general roadmap, open bug and feature tracking, frequent communications, etc. This includes the community in the growth of the project, and shares ownership of it.

The editor would give access to tools and permissions for third parties to have an impact on the code

“Do-o-cracy”

The project is managed by its founder and team (either volunteers or employees), all the while being open from third-party contributions. Trusted contributors can be “promoted” in the project’s decision ladder by their professionalism, their temperament, their attitude and the respect they breed.

To that, you could add the lack of personal interest (contributing for the greater good, not just one’s own), and the ability to sort things out between one’s opinion, the way the project is managed, and the viewpoint of other users and developers. Constantly bringing constructive feedback, showing a willingness to work with others and an ability to give (and accept) opinions in a respectful way – all of these are very important.

Interaction

Once the launching/discovery period is behind, new features are not always enough to maintain the interest of contributors. The project can then open itself to other projects/partners, and collaborate with them in order to each benefit from the other’s experience.

Cross participation, through common events or platforms benefiting both projects, make it possible to open communities on each side, thus growing while still being relevant.

Open Source project can only benefit from being social.

Technology

In the Open Source world, Darwinism is all the rage: you have to adapt or be overtaken by other projects better suited to the modern world.

If a project keeps on using obsolete technologies or methods, there is a risk to not only lose current contributors because of “ennui”, but also a risk to not be able to attract new contributors, for they wouldn’t see the point in diving in a project approaching obsolescence.

Fun!

One new contribution does not automatically means having one more contributor. Sometimes contributors just drop one idea, and are never seen again.

To make contributors come back, the project should be fun to contribute to!
This means being proactive, with quick decision, quick comments, quick code reviews, and quick thank-yous!
This also means being human: a community should do its best to de-anonymize contribution. Having an online presence, writing blogpost, doing webcast/videos, etc.
Contributors should be “onboarded”: they should now that can take more ownership on the project, should they want to.
Finally, talks should not always be about the project and only the project: being humans also means being able to talk of something else, to joke, to post silly pictures, etc. Don’t take it too seriously! :)

There you go! I hope this inspires you to switch from a curious readers to an Open Source enthusiast, and that’ll you want to learn more about contributing to any Open Source project that means a lot to your or your business!