[Bf-committers] Proposal for clarified VFX Reference Platform Support

Benjamin Humpherys benjamin.humpherys at gmail.com
Fri Jan 21 17:39:54 CET 2022


I wholeheartedly agree with Sebastian: sticking to VFX platform doesn’t
seem to have any major upsides from my perspective as someone outside the
VFX industry.

It’s worth stepping back and looking at the bigger picture: what portion of
the millions of people who download blender every month are actually full
time VFX artists? Hundreds? Several thousand? Support from industry is
extremely valuable to blender’s adoption of course, but Blender’s reach
goes FAR BEYOND just the subset of the VFX industry that uses the VFX
platform, and that group always has the option of just using an older
version of blender that fits the rest of their tool chain (or even better,
contributing back any fixes they need to make! If industry wants to
maintain a VFX platform fork, all the more power to them!!!)

I am a full time Python developer in a different industry unrelated to VFX
and my comparatively limited experience is that company management usually
has to be dragged kicking and screaming into upgrading software
dependencies. Blender should avoid breaking changes to workflows
unnecessarily of course, but my $0.02 is that a vibrant and innovative
project like Blender will do more good in the world by pushing forwards.

I believe Blender should explicitly NOT commit to supporting the VFX
platform.

On Fri, Jan 21, 2022 at 8:31 AM Sebastian Parborg via Bf-committers <
bf-committers at blender.org> wrote:

> I don't think sticking to the VFX platform is a good idea.
> Especially since the python versions they are sticking to are in some
> cases not supported anymore (or the support for them will be dropped
> very quickly upstream).
>
> This will lead to issues where we can't use the required python
> version ourselves anymore without considerable effort to maintain the
> python packages ourselves in our Linux distributions.
> Which I would never recommend to do as upstream python developers
> dropped support for it.
>
> From my point of view the VFX platform is for studios that wants to
> setup a production environment and never update any of the installed
> software for 3-5 years. That is fine for them because they will then be
> in an self isolated and frozen environment.
>
> However for development and moving the Blender project forward, that is
> a utterly horrible environment that is very much alike the "waterfall"
> style of product development.
>
> It will lead to very rigid and stale development environment which will
> use obsolete library versions and APIs even before we do a new release.
> Our developers will not be able to be agile when handling library
> related issues or follow upstream development incrementally. This also
> means that we can't collaborate with upstream that well either.
>
> To me the easiest solution would simply just to take the stance that if
> someone wants to use a frozen and outdated target platform, then they
> can simply just use an older version of Blender that uses the required
> python version and libraries.
>
> Otherwise it seems very counter productive for us to try to accommodate
> and supply newer versions of Blender to a system that shouldn't update
> and stay frozen in the first place.
>
> This discussion feels to me like a "you can't have your cake and eat
> it too" situation. There is a request to be able to use a "stable and
> frozen" system. But at the same time it also wants to have the latest
> and the greatest.
>
> On Fri, Jan 21, 2022 at 02:27:19PM +0100, Dalai Felinto via Bf-committers
> wrote:
> > To have studios contributing to Blender is a two-way street. And Blender
> > sticking to the VFX is the least the Blender project can do on its end.
>
> I think we will just be doing everyone involved a disservice to be
> honest. What you are essentially saying is "moving from agile
> development to waterfall development is the least we can do".
>
> When I read this my alarm bells and warning sirens are going off as I
> have seen this before. It usually doesn't lead to the big players
> contributing more, the reverse actually.
>
> You will reduce the incentive to contribute upstream. You can see this
> with for example Android. There, google has tried for a very long time
> to have people contribute to the development. But by creating distinct
> stable versions, most of their potential contributors instead just
> targeted those version and never contributed back anything.
>
> I has gotten a bit better lately as more companies did eventually
> realize that having their changes upstream would reduce their
> development and maintenance costs.
>
> However, this took several years is not decades because there was a nice
> and stable target they could use.
>
> If we listened to what "the industry" would have liked, then we would
> have somehow relicensed Blender to be BSD instead of GPL and the be
> surprised when we actually get less contributions.
>
> So what I am trying to say is that you are saying that you are making it
> easier to contribute while at the same time removing an incentive for
> upstreaming code.
>
> That is a one way street to me.
>
> Regards,
> Sebastian Parborg
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> List details, subscription details or unsubscribe:
> https://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list