[Bf-committers] The Story Of My Attempts At Contributing Code To Blender

[Ryan Inch]

To the core Blender developers.
Hello again, Collection Manager dev here.
Let me start off by saying that I care a lot about Blender, it's been a 
huge influence on my life and an inspiring story of the little DCC app 
that could, and I want nothing but the best for it. So it highly saddens 
me that I feel I need to write this email.

I've been a part of the Blender community and writing add-ons for it for 
eight years and a user of Blender for even longer.  I love the power it 
gives me to create, and have always tried to give back with what I have 
to give (Unfortunately, money is not one of those ways, so I have 
contributed code, feedback, and support instead).

In 2019 I separated the Collection Manager out of a larger add-on and 
submitted it to be included in Blender as a bundled add-on on the advice 
of Brendon Murphy (meta-androcto).  Soon after my submission, I was 
contacted by Paul Kotelevets (1D_Inc) who expressed the short comings of 
the current collections system for complex scene setup and precise 
modeling that requires multiple reference images.  Together, along with 
others who gave feedback, we have advanced the usability of Blender for 
complex setups and increased the capabilities of the new collection 
system.  When I started this project I assumed that it would be highly 
welcomed, because collections were one of the pillars of the 2.8 
project, however, it was mostly ignored.  Still, I continued on with the 
project because it was useful to me and was essential to others for 
their jobs.

In the year and a half I've worked on the project, I've become pretty 
familiar with the python side of collections and layer collections, but 
during that time I ran into problems that I thought would be better 
solved on the C side of Blender, so I spent ~6 months familiarizing 
myself with layer collections and attempting to solve some of the 
problems I'd run into, and then ultimately trying to stabilize layer 
collections as a first step to further improvements.  I submitted three 
patches during this time, one of which went nowhere (and rightly so), 
one of which was a draft and that I used to ask for help when stuck (to 
which was replied: Thanks for the patch, but it's up to you to present a 
working code, otherwise it's likely a loss of time for everybody...), 
and then a final one, which did contain working code.

I submitted the final patch on November 18th 2020 and assigned Bastien 
Montagne, Brecht Van Lommel, and Dalai Felinto as reviewers; two months 
later I updated the patch to the latest master and linked a good test 
file I had made; ~2 weeks after that, Bastien responded that the patch 
hadn't been forgotten and that he'd just had a lot on his plate; a few 
days after this Hans Goudey (HooglyBoogly) reviewed the patch and 
provided some really good comments (he didn't have to do this and I'm 
really grateful to him), which I then addressed a couple weeks later (I 
had been busy and things didn't seem urgent); three months later I 
updated the patch to the latest master again; and then almost two months 
after that it was abandoned by Bastien who had apparently just committed 
his own solution.

As you might imagine, this was fairly distressing to me as I had put a 
lot of time and effort into creating and then maintaining it.  I had 
been content to be patient and not push for my patch, because I thought 
it was of a low priority and I knew from various sources of Blender 
communication that Bastien had been very busy and I didn't want to add 
to the stress he was under.  So, after the patch was closed, I looked 
into the one that replaced it and at Bastien's weekly reports to try and 
figure out what had happened.

On inspection of Bastien's weekly reports, I found that he had been 
working on his own solution for a month or so, but I hadn't connected 
the dots because I thought he was working on stuff for library overrides 
and that if he had needed something to preserve layer collections he 
would have used the already working code that had been sitting in the 
patch tracker for six months (or if a different direction was required, 
told me and brought me onboard with developing the new patch).  And when 
I looked at the patch that replaced mine, I found a comment by Brecht 
saying it was "Great to see this tackled.", as if now that a "real" 
programmer was working on it, it was suddenly much more important and 
welcomed.

There are two issues here, with the first being how everything was 
handled, the lack of communication and the disregard for the time I 
spent attempting to contribute.  I have seen in official Blender 
communications that one of the goals of Blender is to onboard new 
developers, this is a perfect example of how not to do that. Campbell 
Barton once said something in IRC about GSoC students that I have always 
found inspiring:

"Typically for students who don't know what they want they ask a lot of 
Q's... and never get involved.
(sounds a bit negative... just my experience tho)
Basically they waste our time.
People who are motivated don't wait for others to tell them what to do, 
they start interesting projects themselves."

Now I'm not a GSoC student, but I started an interesting project, and 
filled a gap that the core developers didn't have the time to address.  
I didn't ask a lot of questions, because I'm pretty good at figuring 
things out on my own, and I attempted to get involved. When I started, I 
expected to be welcomed and onboarded by a great open source project 
that was in need of more contributors and that I could work with to 
improve a tool I care deeply about, but what I found was a project that 
paid little attention to my contributions, did nothing to onboard me, 
seems to care little for community contributions, and was mostly 
unwilling to work with me.

The second issue here is with the code of the patch (D12016) that was 
approved over mine (D9599).  While as far as I can tell, they are 
functionally equivalent, Bastien's is much slower than mine, especially 
when it comes to many layer collections under one parent.  From my tests 
(debug, lite build, with Bastien's CLOGGING removed so as to match my 
patch) the average time it took to resync 1000 collections when 
configured so that each of the 1000 had 1 child was 612 microseconds for 
Bastien's and 261 microseconds for my patch.  That's almost 2.5 times 
slower for his patch.  When the 1000 collections were configured as a 
flat list under the scene collection, Bastiens took on average 22290 
microseconds, while mine, on average, took only 252 microseconds.  
That's almost 88.5 times slower for his patch.

You may be thinking that 1000 collections is unrealistically high and 
that no one actually uses that many, but Paul Kotelevets (a diamond 
level sponser, BTW) has told me that he regularly uses 7-9,000 
collections in his work, so my test case is on the low side and the 
performance costs of Bastien's patch will be even greater than what I 
have outlined here.

I believe the performance problems with Bastien's patch stem mainly from 
three places, the BLI_findptr which is used to check whether the layer 
collection is valid as a child when generating the layer collection tree 
wrapper with additional data, the method that is used when searching 
through the wrapper, and the fact that each layer collection has to be 
searched out from the wrapper, even when it is already in sync with the 
collection tree.  The problem with all this searching is that for each 
collection it tries to find under the current parent it has to loop over 
all the previous collections under that parent, and this happens in 2 
distinct areas.  And I believe this is also why it's so much slower when 
all the collections are under one parent.

I think the reason mine is so much faster is that it does much less 
searching.  My patch processes the layer collection tree in a depth 
first search and finds only the invalid layer collections and stores 
them in order, then the collection tree and layer collection tree are 
walked through in tandem, re-linking the valid layer collections as it 
goes, moving the invalid layer collections to their new positions when 
needed, and then removing the invalid layer collections from the 
original processed list after they've been added to the new layer 
collection tree.  As little searching as possible is done, with the 
initial order of the layer collections, the fact that they are invalid, 
and the fact that the collection associated with that layer collection 
matches the collection in the collection tree provides the needed data 
to relink them successfully.

I will admit that there's always the possibility that my patch doesn't 
handle some corner case, but nothing was identified in my own testing or 
the review given to my patch, so I think it's safe to say the only 
difference between the two is the underlying method, the performance, 
and the authors.

Given what has happened I'd like to just wash my hands of this and 
forget wasting all of our time with me trying to contribute to the C 
side of Blender and just stick to developing my add-on for those that 
rely on it, but I can't, the performance implications are too large and 
I can't in good conscience ignore this.  I'm willing to try and work 
with you on this, whether that's with my patch, or on Bastien's to 
improve his patch's performance (if it is uncovered that there is some 
unsolvable limitation with mine), but I hope I have conveyed that a much 
better outcome with much less work for all parties could have been 
achieved had I been worked with, instead of around.

Sincerely yours,
an offboarded developer.