If the duplication is due to parts not being effective to share that can be made effective to share at not much cost is not fine. Reason why I say every time something like this happens that area should be looked at to see if we can share code with the other project. Long term it will assist blender more people looking over the code.

But question still has to be answered should particular parts be spun of into libs.

Freen points out something important there are not many good compositors out there. Duplication creates competition and experimentation. But for the competition and experimentation to bare fruit it has to work.

Now key thing here is if you want to create something like Cinelerra Jahshaka or CineFX. There is no shared backend. If you go to create a new music player you can use a shared backend. If you want to create a new audio editor shared backends.

The lack of multi project in this area that works is one of the major reasons why I am saying it worth the time for blender to look at its self and see if its sane to consider break this part off in the lib.

I am for competition. Duplication is good. Duplication of Effort is bad if the area could be shared without causing pain to either project Ie breaking the points tom wrote up.

Results of duplicating effort is getting a stack of unstable programs with very few working ones.

Of course we all would prefer having a stack of programs that works competing with each other and giving us new features. Remember projects cannot get onto new features until the basics work.

I reckon we need several alternatives for each application. It makes for a more robust suite of tools. So far professional standard video editing and compositing has been lacking in the open source world, with Blender being the exception.

Duplication is a good thing.

There’s Blenders compositor and now Ramen. There used to be an app called Jahshaka (or something) thats now called CineFX, but its more of a player in its current state.

If you know any more i’d like to hear about it.

ego – you get more glory and recognition if you create your own project than if you are a contributor to a big project

code – understanding others code is more difficult than your own so developers tend to use the reason that the other code was ‘messy’

language and toolkit – some people prefer working in java, others in c, others in python; some want a kde or gnome or other toolkit bindings – if a project is not in your preferred language or toolkit you are unlikely to contribute

culture – a coder might feel unwelcome or that his patches are not reviewed quickly enough

architecture – the ideas the individual has might not be compatible with the architecture of the project

LetterRip

KDE is great examples of this. Most Image editors in KDE share the same plugin system. Lot of browsers share the same plugins. Best of them all in KDE is Kontact. Multi applications glue together to create one powerful tool. Advantage if a person does not want all of Kontact they can just load up the one part they want only.

Blender has always been a single stand alone program. Very little sharing with other programs. Maybe its time to reconsider that position. Shared engine could make Est job simpler while allowing him to develop his own interface.

Basically what Est has done should have us asking a few questions if blender need to change its design. Now a internal struct change is not a fast process. It could be years before node based systems in blender could be exported. So Est work is good at the current time.

Remember these questions if parts of blender should be exported for other projects to use don’t come up often. The exported lib for reading blender files was a great step forward itself.

We (the Blender community) should encourage developers to get involved, but we should be careful not to criticize those who wish to invest their own time on a different project.