Earlier this year, Blender chairman Ton Roosendaal published a roadmap mentioning a need to investigate useful ways Blender could connect to the Internet. One of the key features was to have a way to automatically get updates for Blender add-ons. This document dives deeper into that topic.
A necessary stepping stone to get the latest Blender add-ons without having to leave Blender, is having a public listing of quality add-ons, backed and maintained by the Blender community. This, we propose, will become possible on the new Blender Extensions (BE) platform, to live at extensions.blender.org.
Purpose
The purpose of BE is to serve Blender users, helping them discover and download add-ons, themes, keymaps and asset libraries, entirely within the Free and Open Source spirit.
BE will only offer GNU GPL compliant software, or CC-BY–SA compatible content. No commercialization will happen in the platform. It aims to be attractive for artists and add-on developers to freely share their work on blender.org, even if they choose to be using third-party services such as Gumroad, Blender Market, or Patreon to generate revenues with the same or similar extensions. Read about that in the Add-on Policies section below.
Whenever the word “extension” is used in this document, one of the following is implied:
- an add-on
- a theme
- a keymap
- an asset library
As we define the roadmap for the platform’s prototype, we will focus on the add-on extension type, as it provides the most comprehensive range of features and requirements which can then be applied to other extension types.
This proposal has been reviewed by several stakeholders, including the people behind similar independent initiatives such as Blender Market and Poly Haven.
Roadmap
Blender Extensions could be split into the following milestones, each of which requires designing and implementing a particular set of features:
- Users should be able to discover, download and rate various add-ons.
- Developers should be able to upload, version and manage their add-ons, as well as to have a way to openly communicate with their users.
- A team of reviewers from the Blender community should be able to help Blender Foundation staff with the task of maintaining overall quality and trustworthiness of listed add-ons.
- Blender itself should be able to access the add-ons listing via an API, making it easier to browse, install and upgrade add-ons.
Each milestone is framed from the point of view of its stakeholders, such as Blender users in the first one, developers of the extensions in the second one and Blender staff and reviewers in the third one.
We will consider the fourth milestone out of scope for the moment. Blender using the extensions listing on its own is something that is planned for the future and should be kept in mind, but it is not the focus of this article.
Public Listing
An add-on listing is a web-page at extensions.blender.org/add-ons/awesome-add-on/ with a description of add-on functionality and a way to download the latest version of it.
Depending on the extension type, the URL changes, e.g. a theme would be located at extensions.blender.org/themes/awesome-theme/.
Each listing item should feature:
- Unique name (also used to generate the URL)
- Comprehensive description and screenshots
- Supported Blender versions and license
- Download link for the latest version (and previously uploaded as well)
- Links to the (external) documentation and issue tracker
- Category/tags of the add-on
- Rating and reviews
- Ways to report abuse
To certain types of extensions, such as keymaps and themes, some of the above mentioned information isn’t applicable.
Supported Blender versions
In case of an add-on, the lowest compatible version could be parsed out of the add-on’s info (such as __init__.py) and the highest compatible version could be indicated by the extension developer manually.
Uploading a New Add-on
To create a new add-on page on the Blender Extensions platform one needs to upload an archive (.zip/.tar.gz) containing the add-on files.
Depending on the type of the extension uploaded, some background processing is done before a listing is created, for example:
- In case of add-ons, the most important part of the archive (besides the functional code) is the __init__.py file containing add-on’s metadata, which is parsed and used to create the listing and the first version of the add-on.
- In case of a theme, a preview is generated based on the theme’s XML.
The slug used in the listing’s URL is generated from the extension’s name and must be unique in combination with the extension type. The slug can never be reused even if the previously uploaded extension using it gets deleted.
The process of updating an add-on is still being investigated (feel free to share ideas!) and will be documented later.
Review Process
It’s vital for an extensions platform to be designed as a healthy and trustworthy ecosystem. This means having a clear set of acceptable practices and review guidelines. Blender Foundation will establish and support a group of reviewers to manage and guide the process. Here is a proposal for the core policies for add-ons.
Add-on Policies
Free and Open Source
Uploaded add-ons must be fully compatible with the GNU General Public License v2.0 or v3.0.
No Surprises
The add-on must have an easy-to-read description mentioning everything it does. It must be abundantly clear from the extension’s listing what functionality it offers, and Blender users should not be presented with unexpected experiences when they download and install the extension.
Content
- Extension listings must comply with Blender services conditions of use (to be published) stating one may not use Blender’s web services to do anything illegal, threaten, harass, harm, defraud etc.
- Extensions offered on blender.org should be fully functional, documented and actively maintained products.
- Extensions should not require any external functional components that need to be downloaded from elsewhere.
- Extensions that (need to) connect to internet services outside of blender.org, should offer access to these sites without additional restrictions (such as login or registration, paywalls, etc).
- If the extension is a fork of another extension, the name must clearly distinguish it from the original and provide a significant difference in functionality and/or code.
- Extensions that are intended for internal or private use, are only accessible to a closed user group, or for distribution testing, may not be listed on the platform.
- Linking to external funding platforms in the description is allowed. It is not allowed to have additional requirements (such as registration, payments or keys) blocking functionality of the extension. (Alternative clause: The extension description must disclose if/when payment is required to access any of its functionality).
Acceptable code practices
- Extension code must be reviewable (obfuscated code or bytecode is not allowed. How to evaluate binaries is still an open question).
- Extension must be self-contained and not load remote code for execution.
- Extension must not send data to any remote locations without explicit authorization from the user.
- Extension should avoid including redundant code or files.
- Extension must not negatively impact performance or stability of Blender.
- Extension’s code must be compliant with https://wiki.blender.org/wiki/Process/Addons/Guidelines
API Specifications
We will consider the extensions API out of scope for the moment: Blender using the extensions listing on its own is something that is planned for the future and should be kept in mind, but this document focuses on the first three milestones of the roadmap.
Current Implementation
The work-in-progress implementation is available at developer.blender.org.
The project is currently led by Anna Sirota with the support of the Blender web team (Francesco Siddi, Pablo Vazquez). This work draws inspiration from the multitude of extensions and app stores available online, as well as various package managers. In particular, the Mozilla Extensions website has been used as reference for the architecture.
Conclusions
Feedback on what was presented in this article is welcome, in particular regarding the process of reviewing content submissions, content versioning and listing.
(As a related effort, I’d very much like to see Blender develop an add-on update notification and download/installation mechanism inside the Blender app that could be used for both free and commercial add-ons. Keeping track of add-on updates is rather painful at the moment)
I take issue with this section:
”
Extensions should not require any external functional components that need to be downloaded from elsewhere.
”
Everything else is totally fine and awesome!
I can think of many add-ons that require the downloading of non bundled pip modules as well as large datasets for AI models that require external hosting. With the rise of tools like Stable Diffusion this system will inevitably need a way to handle downloading large external tools and components like that. Especially if you are catering this and the Blender Apps platform to developers.
A system should be standardized to vet and distribute external components. The Cozy Auto Texture add-on has a good implementation of handling the user awareness side of this in my opinion. Once you install the add-on and activate it, you need to accept the add-ons license and click a big “Download” button with information about what is being downloaded.
I do understand the security concerns, however I think completely blocking this functionality puts a massive cap on the capabilities of the extensions that will be listed in extensions.blender.org.
Instead of implementing your own custom solution I would suggest to use something which already exists, fully open source, solves all your requirements and much more (like: version control with private gitlab, automated packaging, project versioning, usage statistics, handling unmaintained projects, multiple maintainers, contribution credits, automated testing, spam protection). More than 9000 active projects, all GPL, secure without a review process.
https://www.drupal.org/project/project_module
It is available for 20 years now, lot of experience managing all the problems related to open source contributions.
I would suggest to have a chat at #drupalorg channel on https://www.drupal.org/slack
Even the blender developers themselves seem to not understand the ecosystem of products growing around blender, it seems? Asset, geometry node/shaders creators are all shipping their products in a plugin format.
Let’s say, for example, an HDRI creator, shipping his HDRI within a blender plugin for the ease of use of installation/ & users navigating his HDRI’s, changing brightness in the interface ect… The great majority of blender plugins use this kind of format.
This trend cannot be ignored, this proposal seems to not understand the current blender product trend.
Well if they’re doing it via plugins they should stop (their main goal is HDRIs, not the plugin anyways so it clears them of having to do extra work)…
You shouldn’t need 3 plugins if you want to use HDRIs from 3 different sellers.
Using plugins to create a pseudo asset manager is yucky.
You can’t stop this trend, there’s no more boundaries between “plugins” and generic blender products anymore. That’s just what the blender product ecosystem became
I agree it’s bad, but well, you can’t control the users.
# Recipe URL
Maybe not the right time but these great news spawned a supplementary idea that might be good to consider early on. It would be useful if there’s a way for users to create a ”Recipe URL” for any combination of add-ons and/or other assets within the store.
That way you’ll generate URLs that looks something like this:
extensions.blender.org/recipes/#5928486929
People could instantly choose to install a recipe in one single action. This is useful for studios and collaborative pipelines where time is key and the ensurance of conformity is a requirement.
The word Recipe could debatably be replaced with Collection or something else.
Great news.
How about have templates to explain a feature and to add help ?
Not clear in my head but you get the idea.
Very nice initiative since increasing discoverability and review of Addon is a very good thing.
Would Paid addon be display as well ?
Since a lot of them offer fantastic possibility (Flip Fluid, Scatter, Sanctus, etc…)
It would be good to have pip-like dependency management and modules.
The easy to use of opencv-python and pytorch makes addon next level.
… I feel like we should just use a normal python repository, and have addons be “normal” python packages, potentially installable under the covers by `pip`. This solves essentially all of the infrastructure and metadata issues, because all of that is just part of a python package.
It allows this:
> Extensions should not require any external functional components that need to be downloaded from elsewhere.
…to be removed (package lists can be reviewed/whitelists), which enables broader re-use of existing code. Nicely, it allows extensions to take dependencies on each other (which is also sort of a nightmare, I’ll admit, although I believe there are some community extensions that already perform such functionality).
Additionally, it allows the extensions to precompiled as wheels, or even be native extensions.
One question I have, is weater there will be UI / UX Guidelines. There are a lot of really good addons with horrible UI desgin out there. Can we get UI Guidlines to have at least some standards and keep Blenders UI as beautiful and easy to use as it is?
There is a Blender HIG section in the wiki that needs to be expanded but it’s a good starting point. https://wiki.blender.org/wiki/Human_Interface_Guidelines
Back in the day, there was an add-on to install add-ons from within Blender. IIRC I managed to update it in a fork, so the UI was working, but the json was scraped from the old Blender WIKI, and most of the links were dead. Maybe, it could be used as a stepping stone? Installing add-ons from within Blender from your “safe-list” would be really cool: https://github.com/KoltesDigital/blender-addon-registry
For inspiration, here’s a site which scrapes GitHub for Blender add-ons: https://blenderdepot.netlify.app/addons/?search=&page=1&sort=updated
I love this initiative, however, I do not understand why this rules out an add-on channel on rightclickselect?
I have done some work in this area.
Maintaining an addon over multiple version of blender is very hard. Especially with existing addons that were written and working on a version blender that is years old.
I developed a testing environment (using pytest), one that can be run locally and on github actions, to help test an addon and test it against multiple versions of blender. The environment is written as much in python as possible and there is even an option to run coverage against an addon to see if testing is hitting certain pieces of code, if if not, write more tests. Yes it is exactly that exciting!
https://github.com/nangtani/blender-addon-tester
This needs to be as useful as possible to work, almost impossibly useful.
That means things like copying app or other extension stores won’t work- it’s simply not worth it to have an automated ranking and display process like google play, the app store, or chrome extension store.
It MUST NOT be review or popularity based, at least not by default. As well, browsing for extensions should prioritize efficient data, over being able to see only six or eight images with a name and rating, with no other information. Please, PLEASE do not make entries just big squares with an image and name that fill the page with a hard-to-browse or phone-optimized grid.
it would be best if there were:
-sorting fields based on popularity, rating, release date, version, and type. A HUGELY successful version of this exists on pcpartpicker.com, where within any section, there are a number of primary attributes to sort by. Note how many entries fit on the screen, and if each entry was simply half again or twice as thick, there would be room for a brief bit comprehensive description and tag list as well.
-a text-based search, which targets description and name of files. This is obvious- everyone has one for a reason- it’s the fallback for when a tag is unknown or a specific name or descriptor is needed in the search.
-a tag-based search, with a large set of curated tags, always clickable from entry pages to search, and definitely searching multiple (for example, if someone searches “cad model style” and finds the “parametric” tag, it would lead them to more accurate results AND help with future searches, as “parametric” would be one of the ~300 or so standard tags. a small subset of language, but several hundred is enough to encapsulate most every extension. yes there would need to be tag requests. They should simply be nonstandard tags that become de-facto-standard after enough extensions use them.)
-entries should be visually separate elements. having entries all be white squares on a white background with no borders may be chic, but creates a confusing feel and lack of visual feedback. Extension entries should have one base shape and feel, and so on
so- by my arbitrary (yes I am actually aware I’m kinda projecting) experience, Mozilla’s extension browser is pretty good! taking inspiration will definitely be along the right path! HOWEVER, Mozilla’s individual pages, once you click on an extension, are cluttered, filled with boxes all cobbled together like… well, cobblestone.
Please try looking at the curseforge search UI (https://www.curseforge.com/minecraft/modpacks) for both browsing and product pages, but take note how invisible the tabs up top are. except for those, great entry separation and clarity, maximum freedom for designing description, and a dedicated spot detailing versioning, and simple vertical list of buttons for downloading any version available. most importantly, look down below. 1-2-3-4…2363 pages. the user never once questions if their search has been truncated, or certain entries left unseen. Also note that there is no landing page for the game. You immediately open up the search page with everything. all that’s left is to narrow it down. you don’t even have to start searching.
I apologize for the giant text wall, but I REALLY want this to be amazing, so here’s all my pent-up thoughts on UI for these sorts of things.
Very very useful.
Do you think it might be interesting, from a enterprise point of view, to be able to add and manage additional repositories?
Add-ons from different repositories could be clearly distinguishable and not confuse the user.
In this way, third-party services could be integrated and studios could automatically provide the necessary add-ons for internal use.
Thank you,
Riccardo
This could be achieved by defining a standard API, and enabling Blender to reference multiple extension ‘sources’. Something to keep in mind, but not a priority at the moment.
This would solve our current use case in a very elegant way. In the context of big companies, different productions in different studios might develop add-ons generic enough to be useful in other context. Also, the procurement and vetting of third-party add-ons can involve different departments. If we had a way to plug our own add-on store to an in-Blender browser, that would made add-on sharing and exploration a whoel lot easier.
We’d be much more interested in an API definition and a in-Blender client than a full web app.
This looks very nice!
I’m wondering if you plan to include application templates in this platform? Is it an omission?
Applications templates will be handled in a similar way. More on this in a separate blogpost.
I like this idea, but I am interested in a small question, will they leave the possibility of installing addons offline?
Yes, Blender will retain its current capability of installing local extensions.
I like this proposal. As an addon developer I can see the benefit of a centralized place to both contribute and receive direct feedback.
How can I subscribe to keep an eye of this and contribute?
For now, check out the sources on developer.blender.org. Soon there will be a project with an issue board, where contributions will be welcome.
Will you then debloat Blender from addons not developed by BF yet shipped by default ?
Yesss, thanks Ton, this is what we want, a free and open minded community, sharing ressources! this is the best news of this year, and my students will thank you.
Finally, we must understand how our software have been made over the years, because of that spirit :) The free and open source community, on top, non stop :)
I don’t like the URL part.
They should be generated with an ID/entry#, and “maybe” include an optional name which can be changed without changing the link itself, for example how myanimelist.net structures it’s entries: [site.name]/[entry#]/[title].
After you decide a name for your thing, that means you can NEVER change the name from then on. The only option for you to get a new name then, is to put a redirect notice in the page or item to the new version. Maybe you extended it beyond the original’s scope or you later thought of a better name.
The only reason I can see for having a mandatory unique name in the url, is for people that
1) already know the name/spelling of the item, 2) know how to enter it into the url format,
3) don’t want to use the search option, and 4) can’t remember the digits or won’t save the url.
You COULD also do both.
Have the ID as the main one, and have a separate named url that mirrors/redirects to it.
That could be done for everything or for “special” entries.
This will be so good to have all the free and useful add-ons in one place and download/update it with ease.
I hope that there will be some implementations inside blender itself as well. Something like app store or such for blender.
Would be really great to have a bigger platform – for updating Blender itself; a manager for testing branches, alphas etc.
For now, I’m really happy that something is moving in this area, thank you!
This topic has indeed been discussed, and will be covered by a future proposal.
You can do this with Steam already. A non-Steam version of this might be nice, Steam itself is a massive software so if that’s all you need it for it’s very slow and bulky, but if you already have it installed and generally use it, then it’s a great solution.
This sounds promising and like a good way to distribute the asset bundle.
I think some things need clarification:
– Remote code execution should be allowed for auto update purposes
> “If the extension is a fork of another extension, the name must clearly distinguish it from the original and provide a significant difference in functionality and/or code.”
I could think of the case where someone uploads an add-on made by another developer (possibly because the latter is unresponsive or hasn’t touched it in years).
I think this should be allowed.
Why GNU GPL? It makes sense from the rights of an extension author, but what if the extension requires a non free library, and how does modifying the extension personally work if there might not be a central location to send a patch/PR back to?
Blender uses the GPL license, therefore add-ons code should be distributed respecting such license.
Extension URLs should be namespaced by the author (similar to GitHub repos or VS Code extensions). Not doing that will result in collisions and contention about good names being taken. I strongly suggest considering that before it’s too late, as it would be mistake to not do that.
Great proposal.
Since we are migrating to Gitea where every user can have their own set of repositories, we could take advantage of that. Potentially a developer could do the entire management of the add-on there: review, Git branches/tags for versions, and text and images for the webpage.
The one extra thing needed would be some way for a reviewer to mark a particular repository (or individual branches or commits?) as approved or not.
Thanks for the feedback. Indeed some package managers allow to source data from a git repo. In the case of Blender extensions, it’s necessary to define a “bundling” step so that the extension can be installed in Blender. I would be challenging is this is meant to happen in the repo and then pushed, or happen server side. Will think about it!
In Gitea (and GitHub) there are mechanisms to make releases, where it will either create zip files from tags or you upload arbitrary files. Bundling steps outside the repo could be handled that way.
It’s also not uncommon to do it within the repo, for example GitHub pages has the generated website in a `gh-pages` branch, sometimes auto updated using CI.
This generally sounds good.
What happened to the ‘No spam/advertising banners etc.’-policy, which, iirc, had previously ([s]possibly[/s] in Ton’s roadmap) been mentioned somewhere?
Extensions should not contain spam/advertising banners. That’s an ongoing policy of the blender.org project.
Hi.
You didn’t mention it in your article (I guess it’s just an omission) but to perform tasks listed in the “Roadmap” paragraph), a BlenderID account will be required, won’t it?
The “Purpose” paragraph lists what the user will be able to download (add-ons, themes, keymaps, asset libraries), will you extend this list to “Application Templates” and “Geometry Nodes” ?
Blender ID should not be required to download add-ons, but if used it will enable further features (bookmarking, rating, etc).
Application Templates and Geometry Nodes will be addressed in further iterations.
Does the uploader need to be the author of addon? If addon is fully compliant with all rules and requirements, but it was uploaded by someone who bought that addon on gumroad or blendermarket, how will these cases be handled?
Technically it will be possible for anyone to upload GPL code on the platform. What policy should be adopted in the case of ‘reuploads’ is yet to be defined.
If people start doing this, you can be sure the addon is dead and the dev will never update it again since he will not be able to make a living with his work anymore.
At least give us Royalty free licensing. This proposal is not open minded.
All add-ons code is GPL, according to Blender’s license. While assets can be released under other licenses, code cannot. Wether the platform will allow hosting of non-GPL, public domain or CC assets is yet to be defined.
It depends on the plugin, the current interpretation of what a plugin is, is very narrow.
The Substance plugin for example, gaps blender with its own proprietary engine. The current proposal would not allow us to share bridges to proprietary content.
Same for plugins that are only but interface of some very complex geometry node graphs, or plugins that are companions for a collection of 3D objects or materials.
Creativity cannot thrive in limitation. Where’s the « freedom to create » in all these rules ?
Blender devs choose start the repository as GPL only plugin system, is their decision. This assures that code can be auditable, since GPL code prevents by their nature using closed binaries, that can be used as malware. (see https://www.2-spyware.com/hacker-for-hire-group-uses-malicious-3ds-max-plugin-to-spread-malware as an example).
Sure, you could use MIT licensed plugins, but that allows the use of binaries too, so the problem persists.
Even for big companies like Google, making sure that apps and plugins for android smartphones aren’t used as malware cost a lot in time, money and human resources. Not a thing that Blender devs or BF itself can afford to do.
The alternative is to have a closet walled garden, where your executable has to be acompained by their source code (the Apple way) coded in only one language and using only the approved libraries. Not a bad idea if you have the resources to audit every piece of software (like apple does), but for the BF that has limited resources, is not realistically possible.
In order to prevent spam, comments are closed 15 days after the post is published. Feel free to continue the conversation on the forums.