Blender is growing fast. With the success of the Blender Development Fund and industry support, it’s important to make sure that the blender.org project organization remains future proof. Numerous activities around Blender are now performed by full-time employees or people working remotely on a grant.
Together, they take care of many core development projects and topics such as improving code quality, documentation, developer operations and support. All very important, but how do these efforts relate to work done by other contributors or by volunteers?
In the past months, I have been working with the Blender Institute crew to tackle our growing plans (and pains). When a team gets bigger you need operations management, coordinators, and human resources specialists. We need a definition of developer roles such as principal engineers, seniors, and product designers. And we need to define how projects are being organized in general.
After reviewing popular development organizational styles (such as ‘agile’ or ‘squads’) I felt that this direction was a dead-end for Blender. We should not emulate a software company. I believe there is one aspect of Blender we should never give up on:
Blender is a community effort.
As we all know, communities are messy, noisy and disorganized. It takes a lot of energy to get an online community to move in a chosen direction, to agree on things and to get them to collaborate on topics. And even worse, open source communities often lose top talent because the best feel dragged down to the level of the group as a whole — which includes beginners or others still developing their abilities. That’s the main criticism on community-driven projects. How do you combine striving for excellence and the quest for quality with a public project that’s accessible to everyone?
Luckily we already had an answer: the module team organization we’ve used for almost 20 years. It just needed an upgrade.
Let’s divide Blender tasks into three categories. Operational, Tactical and Strategic.
The Blender organization can be held responsible for all operational aspects, facilitating the blender.org project, and welcoming contributions from the community. In these roles we currently employ several people; including a DevOps engineer and forum moderators.
Developers hired by Blender Institute will be assigned to specific strategic projects. These usually have only one goal: to get innovative designs working as ‘MVP’ (minimal viable prototype) and hand them over to the module teams as quickly as possible.
This makes the modules teams on blender.org the “tactical teams” in Blender. That’s where the real open source dynamics kicks in. This is where the actual magic happens. It’s public, sometimes messy and noisy, but often incredibly rewarding and surprisingly effective. Good examples are work contributed in the areas of Grease Pencil and Sculpting.
Strategic contributions to Blender can also be provided by other organizations or teams. This is already happening — for example, NVIDIA and Tangent Animation assigned engineers to help with integrating Pixar’s USD in Blender.
Obviously it’s the Blender Foundation’s task to frequently present and discuss strategic roadmaps for Blender, and to make sure the module teams are aligned. That’s a topic for another post.
Module Teams
Modules are largely free to organize themselves. Each type of module might require different management styles or procedures. Some modules will be more difficult to join (Cycles & Rendering), other modules might be stricter in terms of accepting patches (Core Blender module).
Within a module there are two roles; the “owners” and the “members”.
Blender module teams should be as large as possible. If they grow too big, they can split up. Technical Artists (TAs) must also be included among each module’s members
Module teams are responsible for issues in their own code (the module) but should feel free to move open issues to a todo list to deal with later. Module Owners are held accountable: their role implies they accept responsibility.
Modules can expect wide-ranging support by the Blender organization, both for operational tasks but also for Development Fund grants (to retain essential people).
You can read more about how the module organization works in the Blender Wiki.
New: Rendering Module
The Cycles, Eevee and workbench rendering projects in Blender have evolved to become reliable production quality software, using advanced engineering principles. For that reason we decided to join these projects into one module and support the module owners to invite senior software developers as members only. In that sense the module can operate as a tightly organized ‘squad’, enabled to manage complex design and engineering tasks and ensure Blender rendering remains future proof.
The Blender organization will support this module on an operational level, by providing sufficient developers and TAs to help with bug triaging, patch reviews, testing, onboarding and documentation.
New: Core Module
Members of this module will guard and protect the core of Blender’s software design; that includes the DNA and RNA libraries, the .blend file format, undo system, core kernel code, the windowmanager and editors design, and general support libraries.
Membership of this module will be restricted to people with several years of experience with Blender development. The module will also be responsible for general guidelines on code standards and engineering practices.
Thanks for reading!
Ton Roosendaal
Chairman Blender Foundation
Amsterdam, 15th February. 2021