 Hello. What is BeForArtist? Well, today's your special lucky day because I will be explaining it in detail about what it is, why it is, who does it, and how do we do it, in case you want to do your own fork. So, let's begin. BeForArtist is an open-source fork of Blender focused on a set of interface guidelines distributed and documented freely by volunteers. 100% free. You can find the code on GitHub. You can download it, use it, compile it, work with it, take any commit, use it. Free. Just like Blender. Unlike Blender, though, we have some changes. So, to make things a little bit clearer and easy to digest, to understand what this is, BeForArtist basically on a technical level is over 3,000 commits and changes to vanilla Blender. A lot. Just to keep in mind right now, Blender is about 5,500 open commits with another 3,000 from BeForArtist. It's a lot of little details and things that have changed. So, we need some metaphors. Who here likes to cook? Blender, just like the Blender from the kitchen is like the kitchen. It's got everything. We've got a stove, we've got a fridge, we've got a spoon, a cup, a knife, a cutting board, and especially we've got a fork. So, BeForArtist takes the idea of the kitchen and every one of us has a different taste of cooking. Some people like to keep the cups in the cupboard, some people like to keep the knives in the drawer, some people like to keep things hidden away, clean, and the bench clean. Other people, they like to have no doors on their cupboards. They like to have the knife at an easy reach. They like to have the fridge to the left, the stove to the right, the sink to the front. BeForArtist is a bit like that. It's like a different person's kitchen. You walk in, you can see where everything is, you grab the spices, you start cooking. It's just a preference. Other people like a clean and minimal, super cool, great. That's another kitchen. It's just another way of cooking. And another metaphor to keep it in mind as well, like when it comes to community and development and other ideas is we have a surgeon fish. A surgeon fish is a small fish that loves to clean the big fish. So, it blenders the big fish with sometimes it's pretty busy just swimming around the sea, but maybe it might get some sand stuck in the gills behind its head. They have no irons. It can't scratch it. So, the surgeon fish, because it's very particular and has its own personality and also taste, it likes to eat the algae from underneath the gills behind where the big fish can't scratch. So, BeForArtist and the developers there and the people who use it are the ones that are like very particular and just want a different way of doing things. So, let's take a look. So, what do I do with this particular project? Well, I work with development. I work with Rainer, who founded the project eight years ago. I work with Yard Ahmed, who is a legend, a hero, a close friend, and I really care about him a lot. This project couldn't have been without those two. I came in maybe six years ago and I also work with Juicer with Sean and we do development together. It's a team effort and it's volunteer work in our free time. I do DevOps. I help with the release, which means I go back to Columbia and as soon as I get off the plane, I'm on the computer working on the next release. Because we try to stay up to date with Plenda. After that, I also do sponsorship. I receive some sponsorship from some benefactors, well, not really benefactors, family. And I sometimes redistribute the sponsorship in a way of bounties and things like that when I can. It's not a lot. So, what is the target market? As we mentioned the surgeon fish, the target market is about artists. It's about the individual. It's about the cook, the person in the kitchen who wants to eat. The artist wants to make a cake. The artist wants to make a big, nice slab steak. Maybe wants to make some muffins or a nice stir fry. Each artist wants to express themselves and tell a story. The individual artist, the indie artist, the solo artist, the hobbyist, the artist in the studio. It's more about the particular artist and that's why we try to focus on that particular market. Slightly more laser focused than the general market of Plenda. So, what do we do with Plenda? How do we complement? What is the symbiosis? Just like the surgeon fish, the big fish benefits from somebody cleaning up the gills. But also, Plenda has 100% of the open source 3D community. We have about 12,000 average downloads per month, which adds 1%. So, Be Frider's Target is a market that may not be happy or who like Plenda, but they will come from another angle. So, a little bit about me. I used TrueSpace when I was a kid. I learned that it was my first love. I loved it so much. Full of icons. The whole interface is icons. Then I used Softimage. The user experience is very nice. Super streamlined, very efficient, very non-destructive as well. Loved it so much. Then I got to Blender in 2.74. I needed something that wouldn't die because TrueSpace and Softimage just didn't work. I found this particular project, which added a personal taste of iconography that I really liked. That's why we continue developing this even today. We add to the Blender community with an extra 1% of users that potentially may have never or won't want to use Blender. So now we're 101% of using Blender features. I think that's beautiful to be honest. After that, why do we be for artists? To be is the reason why we're here. We're about the story. We're about the cook. We do the code. We do the documentation. We do the work for the artist. That's the origin of the name. That's why we do it, to keep it in our mind always. So to do that, we have to focus on the seven pillars of our vision and philosophy on the user interface guidelines. So the first, we're going to go through each seven of them. And then I'm going to have a little bit of a tour because, lo and behold, whoops, I'm doing this in another software. So the first pillar that we have here is number one. Why is it doing that? Top-level access. So top-level access is our first pillar, which is a big one. Mainly because we prioritize point and clicking. We like to use a mouse. We like to point on it. And we want to work with it. We try to expose hidden floating menus. So Blender has pie menus, for example. But if you ask somebody, where do you find a pie menu in the interface? You can't. It's not exposed in the interface. There is no guided user experience to show you how to use a pie menu unless you memorize or find out what that hockey is. So we expose those hidden operators and we show that pie menus exist inside the interface. You can see that it has a hockey assigned to it and you can discover it. We also try to keep things kind of in a service level. So imagine you want to get the pressure cooker. The pressure cooker is in the back of the cupboard. So you've got to move the pots and the fry pans and the wok and you move it out of the way to get to the pressure cooker. And then you can start using it. So in this case, we try to have a philosophy where anything that's beyond three levels deep or two levels deep, bring it up to the surface. If it's common use, bring it up to the surface. If it's too deep, bring it up one. We try to keep things not so deep so you don't have to zig-zag so hard. Top level access is really important to us, especially when it comes to pointing and clicking in the interface to discover everything. The next thing that we have is iconography. When you first open Beef Radice, you see a huge Christmas light show of icons, mainly because I don't like reading. We're a different type of cook where we're not looking at the labels. We're not looking at the name of the pot. We just want to see something, grab it and use it. So when it comes to neuroscience and a concept of art and developing something that can read, you always start with silhouette and contrast. And from there, you use color. So we're hunters. We're out there in the wild and you can see something kind of crazy and interesting and you see something move around to the side. You see like a shape. That shape is what you first see. It's the first thing you process. And then you're like, oh, was that shape a dangerous red color? Was it a dangerous animal? Was it bright orange? Was it tiger? You see the color. Then from there, you start looking at the details after you've captured what that object and shape is. And then from there, we look at the details. Was that berry the thing that we saw in the bush or something just briefly? Does it have good skin? Is it fresh and ripe or is it rotting? You look at the details in the form. So we use that philosophy with the iconography. Blender currently has maybe 800 icons or so. Right now we're running at 2,500. So how do you differentiate 2,500 icons with just lines and one or two colors? So we've redesigned the whole entire interface and we made everything iconized, every operator, every prop inside of panels and things that we need. Everything has an icon so that anybody, regardless of the language, can see what it does, can relate it with the colors and move on and just point and click and target it. Differentiate something out of 2,500 different icons. So that's a key aspect. It's not for everybody. Sometimes it's a bit of an overload stimuli, but it does help when it comes to general use for some people. Our third pillar, as you can see, oh, just to expand on that, we see what an operator does before reading with a direct visual cue versus exact movement. We have visual targets to mouse over to and this saves a slight pause of moving our eyesight to read something. To expand on the neuroscience behind that, a baby is born with not very clear eyesight, but they can see silhouette. They can see color. They see all the bright colors and they even see and hear the colors. And they see the silhouette and they know what to do with that silhouette to feed themselves. And from there, later on in life, we learn to read. So reading is a second nature kind of ability that we learn that requires more cognitive power to use. So for the efficiency of pointing and hitting and targeting things, we use the iconography to target that primitive state of the brain. So from there, use a customizability. When it comes to blender, blender being open source and being really nice and cool and flexible, we can also use toggle toolbars, toggle customizable tab tool shelf, customizable top level overlays for toggles to make life easier. As you know, we're all cooks. We're all artists. We maybe have a particular way of using our spices, a particular way of frying something. Maybe we use a wok to cook meat. I don't know why. I don't know why we do. Some people do. Some people don't. And we mix and match different things. So we try to give a personalized experience with everything. So most of the things that we've developed for blender are either opt out or optional, which means you can customize your user interface for the workflow that you need. A typical example is I will show you in a moment. The fourth pillar is discoverability. We often show hidden operators that are often hockey only. We show tooltips everywhere, even on enums, which means it's the type of code that usually has the same tooltip for different operation types or props within the operator. And we expose hockey exclusive ventures to the GUI, for example, the pie venues I mentioned earlier. So when we show these things out and adding tooltips, adding a bit of a description, expanding tooltips, adding operators that once were hidden inside of a hockey only operator, which there are quite a few inside blender. More than a few dozen. It makes things a little bit discoverable inside the interface so that any cook can come into the kitchen and see it and use it. The other thing that we try to focus on is consistency, which is, for example, a repeat hopper, repeat hotkey or repeat operator. We try to keep one path to it. Unless you choose to go to the operator through another way with an opt-in option, we try to make it clear and minimized. We also focus on operator names and menu order. So, for example, there's a view menu in all of the editors. The view menu has some operators in a certain way. We make sure that all of the view menus has the same order. If you try to do this in blender, they're all mixed up and changed a little bit. So, we want kind of a muscle memory inside the menu orders in general where it's relevant, wherever possible. Lots of tiny little adjustments. And from there, we also try to focus on user experience when it comes to different operators and modes and objects by fine-tuning some small things here and there, like brushes, the way you manage your swap colors, the props that are exposed in the different types of ways, just little details here and there to make sure that it's slightly polished. And then from there, we focus on reference documentation. The reference documentation, we don't know how many people read it because it is nearly 3,000 pages large and it's a PDF or multiple chapters, but we do this more for the developer side, mainly because we document the interface piece by piece by piece, panel by panel by panel, operator by operator by property by last panel. Everything is documented with a reference, meaning that when we do a task, we document it. We do another task, we document it. We make sure this documentation is up to date to make sure that things are working in a consistent way in a logical order and that everything is clear and consistent. It's downloadable offline as well, so you could use it in like a low internet resource area and it's also done in an open-source way with LibreOffice without using code. There's no markup. There's no compiling. And then we just share it on the internet. We get up and get through. And the last but most interesting part that we're still working on, it's been an ongoing process because this is a love child. It's a volunteer project. There's not a lot of time goes into it because we always try to focus on less hits are the best hits, which means we need thoughtful defaults. The less... Well, what do we consider a hit in the interface? A hit is, I guess, what you could say is when you move the mouse up to open a menu, that's a hit. You move the mouse back down and you click on it, that's a hit. You press one hockey, then the other hockey, and then you move the mouse and it goes to somewhere else. That's three or four hits. So if we have less hits to use, Blender, it makes it slightly easier to use. Maybe you save 20%. Maybe you save 30%. Maybe you save half of the clicks to get the same job done. Less bureaucracy, more efficient, and happy use. So with that, I want to show and not tell. So in the interface, for example, in the side panel here, when we're animating inside of Blender, and you have a selection of bones and a selection of objects, and I want a keyframe, just one of these. I can right-click on it and I insert a single keyframe, but it would only work on the active object. Then from there, I'll have to click on it again and copy the keyframe to the others. So in this case, I'll use a keying set. Or I could just hold down Alt and Record, and that will record a keyframe on everything that is selected, bones or objects. This is something Blender cannot do. That's a user interface thing. Or if I want to, say, export alembics often, I can take a look at one of these menus and I can choose which one I want, and now I can do that. Or I just want to, like, click the Recovery button and it'll reload the scene and everything should be fine. Or I can save as or open a new file directly from here. So alternatively, in Blender, I'll be using a hotkey, opening up the menu, moving the mouse down, selecting. Or hotkey, open up the Quick Menu. I marked it before, scroll down and find it, read it. There's no icon in the menu, unfortunately. And then click it. Or click on File, scroll down, and then click on Open. So all of them have an extra movement or other on top of just Open. Other things we have, for example, I change the wireframe often, but I have a very crowded Quick Menu. So I can expose the wireframe toggle to the header and when I need it, I just click on it and I can show the wireframe on or off, lock the view, show the camera, lock the camera, et cetera, when I need it so that I can move the camera and stay in it when it's locked or when I want to move out of the camera and keep the camera where it was as the blend default. Without needing to go to the View panel, View panel here again, then Lock Camera to View. One, two, three, four steps versus one. The other thing as well here is in the side panel with all of these options. If I use the Mirror Operators often over and over and over and over again, I could add it to the Quick Menu. I could use a Hockey, press M, then press another Hockey to get the axis. One, two, three actions. Or I can just mouse over and click. And if I want to, I can pin the panel and move it up to the top or to the bottom and use it whenever I want. And I also have three columns when I need it. Same with the menus. If I'm in, for example, I'm using the Sculpt mode. Let's see if this goes into it. I won't go into Sculpt mode. Here we go. So if I'm in the Sculpt mode and I'm using Face Sets, and I want to initialize a face set by a certain way, unless I've already remarked it earlier, at least I can see the Material icon and understand that it is a material. And if I want to, I can even store my brushes inside the add-ons that we have so that I can have multiple clay brushes exposed to the top level. So that I could have a lot of, like the Zeta brush type of workflow where I have 10 different brushes for the clay sculpting. I can store it inside my libraries with my own custom icons. Everything should be fine and ready to go. Or if I'm in animation, there's a lot of things that I can work with. So let's go deeper. Or just in fine detail. Also with panels, if we take a look at the panels here, if I look down at this dropdown and show the overlays, I'm not showing the grid at the moment. When you show the grid, you have all these operators up here, XYZ, I don't know why the X is not showing. It's probably my laptop. And from there, I can hide it and indicate that there is hidden content to keep things minimal and organized. More often than not, most artists will not be using motion tracking. They will hide all of those properties and indicate that it is hidden. This is something that we try to do also with organization of props and panels. We always have a label, we always have an indent. We do this consistently, absolutely, everywhere. So that we can group our ideas in a similar way. There was a very good talk about addon UX here just yesterday about that. So we try to implement that directly inside a blender. And just a side note, this is blender. We try to keep up to date with this. And it is practically blender. It just has a different interface or a polished interface. So what else do we have? What else do we have? Let's take a closer look. All right, full screen. Next slide. Customizable toolbar, which I really love, thanks to Rainer. The 3D view tab shelf, thanks to Iyad Ahmed. He's such a legend for doing this. I love this tool shelf a lot. Saves me so much brain power. A little bit. Another thing is 3D view overlays, the ones that I showed earlier. And from there, the options, panels and indents. And we also have the 3D view sidebar with the animation. And we also have the properties editor. For example, down here in the bottom left, we have the transparent toggle because it is relevant to the alpha channel of a file. So we made it grouped in the same area so that if an artist comes from another software, or they're saving something in Photoshop, they know that inside of the file dialog you store alpha inside the file export dialog. This is the file export dialog. There is the transparency toggle. Just familiarity with some other standards. And from there, we also have other changes. For example, the node editor. So I node editor and take a closer look and make like a geometry nose. I have this panel here. Typically, I would shift A or add in the node shelf. Maybe I'll start typing to search or I use the search operator in here and I find the node if I know the name. Maybe I'm using a different language and it has a different name. So in this case, we try to keep things also exposed alternatively in Photoshop. If you memorize an icon, you can. And for example, if I'm using a a color node like this and I have it like this and I change the name. So for example, this is going to be my main color. The icon on the header still remains the same so that I know what is the node. Even if I've changed the names and organized my trees and I can just click multiple lots of joint node geometries I can just quickly mouse over and click multiple times to add these nodes. So to add four joint geometry nodes I'm either create one, select, duplicate four times, shift D, shift D, shift D instead I just mouse over and click. Other things as well that we have in mind from the node editors is we have oh, where did my camera go? The animation user user experience. So for example, when it comes to animation layers Blender does have that typically the default in Blender when you create an animation clip is that it is replacing the animation below it. So when you're layering your animations these animation clips override the other as if it was isolated. When it comes to like thinking about the defaults we created it so that when an animator creates a new animation layer it uses the combined default so that we have animation layers built in directly when you create a new clip on top of the other as a default. Previously you would have to create a clip, create a track, change the clip change the track, create another track create another clip, change the clip property and then you have layers. So with these types of concepts we try to make it simple and easy so that animation layers is something default functioning. If I want to isolate the track I just press the star button and that's isolated or I tab into it in the isolate mode instead of the combined mode. That functionality of having it replacing the track below being isolated is already part of it. So that's what we try to work on. There are a lot of things, lots of little details. So after that it's a lot of work. We've also done some things into the outliner like quickly changing over the files and also like checking out the different slides. Currently on scene 29 in this particular case to manage scenes you would have to use this drop down up here and so now you can use right here if I'm working with hundreds of shots or dozens of shots I'm using an outliner on a different monitor what do I do? Well I can easily just find that scene and I can copy it with a right click. Inside a blender the only thing that I can do is delete but if I'm managing scenes, if I'm using my shots and I'm doing these scenes to work on different things we try to think of exposing operators that you would typically use in the editor that is in the API but is not discoverable. So we try to make it a bit manageable to work these different things. Same with these drop downs for example. If I hide the objects I don't need to see them all until I activate it again. And a number of other things like iconography and others. So there's a lot going on. So with the add-ons we also added functionality with resetting the view, a smart delete so that when I select a face press delete it's gone just like it would in most other software. I select a vertices press delete it's gone I also have a brush panels add-on which I just showed you cased earlier with the brushes and things like that so that we can have multiple brushes in the same brush settings I'm happy that blend is working on this soon. I hope it comes out soon so that it's redundant. So now we get to the big question. This is a lot of work 3,000 base changes to the blender core. It's been alive for eight years. How do you maintain a fork? This is why we hit. So a fork is basically an independent distribution or an independent kind of bridge from the side of blender. So if you think of this orange line up here. This is the blender main branch and this blue line is the beef or artist master or main branch so we have a separate trunk which we can distribute freely to other people in this case our users are free. If you're working in a studio or if you're working in a with your own pipeline this is where you have your own version kind of like an add on main and this is where you would work. So we need to commit to branches and master to do our development but in this particular case we always work with a side branch when we do our mergers. When it comes to the code we stick to about 20% of the code as python for the interface but there are some things that we need to change at C. There's a lot of things we need to do and with that we have things very heavily commented inside of the code, heavily commented almost every line other than icons or tooltips is commented. Why? So that we know when something is going to break. This process is a weekly process we have to do it by week because if we don't do it by week the development from blender is too fast and then it becomes too big to manage. So this is a constant job part time or full time. So when we merge the blender main into our synchronization branch after we merged our master into the synchronization branch we start to see a lot of errors, a lot of problems everything's broken. Some of the documents butt heads and because that happens we have to go through the commit logs find out what changed, task by task by task which could be hundreds of commits from blender every week and then make sure that everything that's relevant to what we're doing is up to date working and clear that they follow the paradigm. Does it have the iconography? Does it have the tooltips? Does it have the documentation? Is it in the correct place? Is the property in an option? Instead of a header menu is the option in an option panel is the a lot of little details. Then we update our tracker in a granular way and then we pull the sync once it's compiling and ready to go once it's perfectly squeaky clean then we merge it to main and we continue doing work. Sometimes this work takes about four weeks. Sometimes it just takes four hours depends on how fast blender is working and it's tricky but it is very important. Why do we have to do this weekly maintenance before we do development? Because we need to future prove the project we need to make sure that it is alive living and well for the long term future. We've got to resolve the conflicts, go through the commit logs sync all the add-ons make sure that they merge together the same philosophy as everything else for example the node wrangler or the import-export add-ons and the biggest most difficult document to maintain in the fork is the space 3dview.py because this is a massive editor it's the biggest editor of the whole blender document area so we can't merge this document this has to be spliced in manually our workflow in that particular case is we compare blender for one week ago with this particular document with blender this week we see what changed oh that changed why from this commit? let's grab it, manually put it in make a task, update it and carry on because if we do an automatic merge we either squash our own issues or our own updates or we've destroyed everything we also update the default theme which requires recompiling it new icons require recompiling the documentation to keep things sharp and from there when we're ready, after the maintenance after we can start focusing on feature updates because we don't want a version of beified as distributed to the people that we use suddenly stop working because we weren't staying up to date with blender, we have to stay at the same speed so this is the importance of granularity hey why did it do that there you go so here's the tracker so when it comes to the tracker the tracker is very important we chose to use github because it has discussions and we have the ability for feature requests we try to listen to the artist we being for them so we need them to talk and we need to have a way to track so when we have a discussion we can convert a discussion into a task then we can create a branch from the task and work to it or we can have a discussion about it and say nah it doesn't fit the 7 pillars that we have good good suggestion but sorry we can't develop it we tracked it, it's closed, it's now done another thing that we try to do is keep it like a very clear that it is everything needs to be tracked granularity so how do we troubleshoot the more granular we are the better so now we need to focus on troubleshooting we try not to touch the core features of blender we try to keep feature parity of blender make sure that all the features are working side by side but sometimes we find a bug when we do find a bug after we've got a work in compile after everything is working okay we ask ourselves does this work in the source is it with me or is it with them that's not the case if it's not a bug in blender then it is definitely the forks problem so we got to make sure that we compare the code, make sure that we rebase go through everything that we've done in the weekly maintenance and then try again so it's a logical process and then from there like I mentioned earlier we link every task to documentation and this keeps things very sharp keeping documentation updated and organized and to make sure everything is okay and then when you maintain a fork not only are you just doing the work of maintenance doing the new features keeping things going, keeping your job going keeping the work going for your studio or for whatever way you have to also think of staying up to date with the blender release cycle with the weekly builds and official releases we don't do daily builds though GitHub does do it sometimes the reason being is that we try to merge once a week once a week because it is a lot of work to do it every day we try to do it in a weekend because it's very quiet in the blender foundation that means there's no new code happening so the weekend let's do the merge while they're all sleeping and then from there we have a weekly release that we leave for free for everybody to download from the website and to test out so that's something you got to keep in mind how often are you deploying how often are you going to do the merge how often are you going to work with that so let's talk about the juicy, interesting part the symbiosis with blender what is the history of BeFu Artist and how did it influence blender or how has it been maybe influencing blender how do we share code or different ideas or user interface things I guess we can take a closer look so ever since BeFu Artist came into being from version 1 which is a blender 2.79 era we had workspace tabs we had an iconized buttons in the tool shelf and we had a left click select default these ideas I think were common knowledge that everybody liked and when 2.8 came out we celebrated we were having a good time because we had workspace tabs that we could create custom workspaces we had an iconized shelf with modal operators now which means our brains just lit up bigger buttons and they gave the option of a left click select and on top of that throughout the years sometimes we have new things so when do we commit upstream our focus with BeFu Artist this is usually the interface the user experience and having a good time but when do we decide to say hey this is probably better in blender let's try to commit to blender and hope it works in this particular case feature updates user operators operators and things that I need to work inside a blender before I think about it in the interface if it's not in the interface in the way somebody handles something but we need a new way of handling something we commit it upstream so in this case for example Iyad has done some work with making sure that you can batch rename scenes or batch rename textures no sorry brushes this is a work request that we needed for some certain things so we committed this code to blender directly and it got in and we can all enjoy it now so I highly recommend when you're working with a fork and you're doing it on your own draw a line when should you commit to upstream so that it bleeds back down and you don't need to think about it so much and then focus on what you need to do so what is the legacy the legacy of BeFu Artist is the following we want to walk the talk the history has been really good when it comes to the development we've developed these ideas with a working board with a fan base that likes to use it and with ideas of how to use blender in a friendly way or a fast way or a different way or more visual way it doesn't really matter it depends on the cook or the artist we want to show the prototype show the example give it out there for free document everything that we do in a very granular way Google icon has a task that you can track or find and use and we show that example with something that works we walk the talk and that is our legacy and from there we just want to cook art pretty much and that's why we do this particular software I'm currently working on a painterly music video project within BeFu Artist and I do all my client work in here I guess I'm a big beta tester I suppose and with that we try to grow the community try to grow help other artists work more on customer support try to get ideas try to implement things even get discussions going and just if something is not done within blender we can fast track an idea and get it going before blender can so we offer an open source alternative for potential blender users that may come from other software for example Max or Maya or old software like Softimage or TrueSpace who are not too keen to use vanilla blender or they tried and they didn't kind of feel at home or maybe they don't want to use the defaults and we want to do this while providing a working vision of a GUI paradigm an alternative based on the source not a competition but based on the base for the community so what's in the future the test project the painterly web series has a number of episodes more to do and we want to continue developing the community and grow we also want to get some good presets for artists secret is out we might get some node groups for shaders shipped as a default and also we want to develop a better knowledge base so that it's a bit easier to pick up technically when you use beef writers all blender material add-ons if it's compatible with the latest from blender in other words we're already running on the 4.1 base which means if an add-on is broken in 4.0 or 4.1 you may find difficulty in the next release but we don't have much of a choice here but we want to make sure that we're always branching and always forking from the blender main to future proof it or else the branches of an official release usually stray too far away so when you're doing a fork I also do recommend this as well when you're building your fork try to stick close to the main and do not fork from an official release because over a few weeks over a few months the whole release cycle it will become almost impossible to maintain your code in a sustainable way so fork from the main and with that this comes to the end of this talk so I want to say thank you I hope you're happy