As the previous post, continuing the set of posts regarding my subject about Study Cases, today I’m going to continue with Gnome, but this time regarding The Gnome Community.
As the previous talk about Gnome, this talk was driven by Carlos Garcia Campos, active member of the Gnome community and the FLOSS community in Spain.
This post is being written following the slides which Carlos used in his talk, when I have the video, I’ll post about I’ll find interesting.
So, let’s go.
As Carlos said in his first slide, Gnome is people, as many other FLOSS communities, Gnome is driven by people for people.
In Gnome we can find several teams regarding the different objectives and scopes of this project as:
- Usability (Designers).
- Bug squad.
- Build brigade.
- Release team.
- And may others.
2. Coordination and Communication:
Gnome as other FLOSS communities has several ways to communication and to coordination between its members, both synchronous and asynchronous:
3. Module-set organization:
Gnome is big, really big and it’s divided into different parts:
Core, where we can find the libraries, utilities, user experience modules, OS services, etc. It’s the most important stuff of Gnome.
- Core deeps, other libraries used in Gnome.
- Apps, application which are in the Gnome desktop usually as default, or to download and there are part of The Gnome Project, as gedit, evolution, totem, rhythmbox, etc.
- World, another applications outside of The Gnome Project.
4. Gnome software:
All the Gnome software, application and different parts (libraries, toolkits, etc.) are under the general rule of use GNU GPL for applications and LGPL for libraries.
They have plans to switch to GNU GPLv3.
Every module has one or more maintainers to make releases and make decisions about the project.
Global decisions are discussed and made by the whole community on a public mailing list (desktop-devel-list).
Gnome uses meritocracy as the way to have more or less rights or decision power in Gnome project. As much as you work more importance in the community and rights (as commit right, revision, vote, etc.) you will have.
5. Important development roles:
5.1 Becoming a committer:
- Any person who has contributed a reasonable number of patches can be a committer.
- Committer requests are handled by the Accounts team.
- Accounts team contacts the module maintainer or translator coordinator to check for approval.
- A committer can commit to the git repository, but his contributions have to be reviewed and approved by the maintainer of the module.
- Committers have write access to all git repositories hosted in git.gnome.org.
The maintainer is the person responsible for a module and do the next tasks:
- Makes the releases.
- Reviews patches.
- Makes the decisions about the module (Roadmap, features, priorities, etc.)
- Is the main contact for the community (release team, packagers, reporters, users, etc.).
- Benevolent dictator is the way to follow when in the decision takes they don’t have an agree.
Maintainers don’t need approval to commit the module they maintain.
A module can be maintained by more than one maintainer and a maintainer can maintain several modules.
GUADEC (Gnome Users And Developers European Conference) is the annual European Gnome event where the Gnome community meet them to talk about Gnome, take decisions, etc.
Since 2000 it has been an annual party each year.
7. Development process:
The Gnome development process is an strict process to allow and ensure the correct release of a Gnome version following their guidelines and respecting their deadlines.
- Six months release cycles coordinated by the release team.
– Feature proposal period (new module proposal).
– The freeze (String change announcement period, API/ABI Freeze, Feature freeze and UI freeze).
– String freeze.
– Hard code freeze.
All freezes except the hard code freeze remain in the stable branch after the final stable release.
8. The Gnome Foundation:
Is the foundation which controls The Gnome Project to ensure its quality, rights, provide founds, etc.
- Central point of coordination.
- Public representation.
- Contact with companies.
- Legal and economic stuff.
- Comprised of:
– Board of directors (currently 7).
– Advisory Board (organizations and companies that support Gnome (currently 17).
– Gnome membership (currently around 348). Any contributor to Gnome can become a member.
As contributors of The Gnome Foundation we can find members as Canonical, Collabora, Debian, FSF, Google, IBM, Igalia, Intel, Mozilla Foundation, and many others.
9. Gnome Hispano:
This is the Spanish association which represents Gnome in Spain, was created in 2005.
Gnome Hispano also drives the GUADEC-ES event (the internal Spanish meeting).
Others Gnome hacker meetings, etc.
As we said in the previous post about The Gnome Project and its history, The Gnome Project is a really important FLOSS project, which is not just software is people, a lot of people involved in different things, development, marketing, releases, etc. As many other FLOSS communities this project is under a NPO, The Gnome Foundation which is really important to maintain and preserve the project.
This project as we have seen is under the meritocracy model, which is really good to avoid long problems, misunderstandings, votes, etc.
The foundation also is well structured with the corresponding boards, members, etc.
The annual event is a really good way to put-the-face to developers that maybe just know each other trough the email or chat.
Finally, the Gnome Hispano chapter is a really good idea and way to have close the Gnome Hispano community.
You can find the slides which Carlos used here.
And that’s all my friends.