I’m a dev in training but soon we maybe setting up another studio over seas (if all goes really well and the universe aligns).
If that happens we were looking at putting on devs for Natron but the more we look at this we kinda feel taking the best of everyone and trying to pack it into blender (I know that everyone loves nuke but can we get over it).
That said for us to do that we need to be making money from all of this as well just to organise all the devs and and set up a road map and training to make more devs as well as promotions is alot of time.
On top of all of that would be documentation and testing.
I think for natron we put down something like 8 devs to be working on natron and blender. Right now we are looking at opentoonz and what it has to offer.
There would need to be someone to “pass the flame on to” first. Those developers haven’t shown up yet. The main Natron developer is around and is totally willing to answer questions. His time is limited though. Previously development was sponsored, you can read more here.
It’d pretty much have to be a paid gig.
Yes, we should be looking for new devs.
Yes but that community was not easy to build and has taken years and years.
That sounds good, but is probably a ton of work.
This is an animation application and not really the same as Natron or Blender. Its workflow is geared towards scanning drawings and animating from that.
should we just ask https://www.inria.fr/en/ for the code of Natron 3? It worth a shot right? or has some done that already? Is the code somewhere online?
@Adam_Earle check out Olive Editor. It’s a new NLE that already uses OCIO for color management. It obviously doesn’t have nodes or Nuke style compositing. It’s also based heavily on GLSL shaders, and has a streamlined modern design.
Any discussion about GPL NLE’s / compositors has to include fundamental image processing pipelines. It’s not enough to copy the look of great proprietary software, it also needs to work- get the job done.
With a bit of investment I can see Olive being very successful not only for the creator, but also users.
I am not quite sure what you mean by asking for the code - it’s open source. Also it seems you aren’t quite up-to-date, e.g. as far as I know inria isn’t involved anymore. I suggest you have a look at Natron development status? and Crowdfunding Natron 3d Workspace, possibly GUI overhaul with QT 5.12 - #11 by razorsharp as it would probably the most pressing issue if Natron was continued on it’s own (as opposed to e.g. your Blender integration idea), as qt4 reached end-of-life.
Recently I’ve needed something like AE… but on GNU/Linux and opensource (what else?!)
I’ve found Natron by using https://alternativeto.net/
It looks very promising, but… I’ve seen this huge banner “Maintainer Needed”
I’ve take a look to the git repo and tried to build it myself on my Fedora 29.
That was not easy at first time (I’ve been terrified by the SDK installation script and all these patches…), to finally don’t build SDK at all and just use a simple Docker base image.
My binary is now successfully build, and as I really need this application, I can officially give a bit of my time to help for maintenance and dev.
Fast resume: I’m a senior software developer in Embeedded SW, specialized in GNU/Linux and OpenSource technologies. I’m doing kernel driver, SW design, projects management, dev-ops, etc for various industrial customers.
I’ve also ported Python and Blender (in early 2000’) on a non-POSIX platform, PowerPC based.
I’ve got a bit of free time each day during the next couple of months, so if I can help, it’ll be a pleasure. For sure, I’m not a Windows or MacOS developer, but I’ve some contacts that may be interested by
I’ve take a look to the Issues list on github (I’ve replied for the timeline bar issue with GCC8.1).
But my first notice is to cleanup the build system in general and dependencies, at least for GNU/Linux based platforms. It looks like a nightmare to maintain.
If some people has free cpu time for me to test binaries and/or build systems, let me know in PM what kind of system you have (only GNU/Linux for now, sorry for Win/Mac, as I’ve said I’m not a dev on these platforms)
This is an easy one… I’m familiar with Redhat base stuff (also with Ubuntu in fact).
But I’m looking for ArchLinux users (to make the deps list and know what to put into the dockerfile)
@yomgui if you could contribute a docker image with the SDK that would be great. Some of the patches are needed, especially the Qt4 patches. Ideally, this should be a docker image based on centos6.
As this thread is about future, we must talk about… CentOS6
It’s EOL is for the 30th November 2020. Currently it’s care stage is “security-patches only”.
So, I know Frédéric said me that CentOS6 release is the reference build, but we’ve to be lucid.
Build for this platform is like making a full OS release (ok… I’m exaggerating a little bit, but you see).
There are tons of patches to take care (even gcc is rebuild!).
how many maintainers other than me has the time/knowledge to support it?
even with maintainers, what’s the time to support it for only 1.5 year of support? (after EOL, repos can disappear, no ones is able to (re-)install it)
Since yesterday I’m fighting with invalid URLs and Natron build system to make a SDK, I even not started Natron itself.
You see, using another reference platform for the GNU/Linux is a mandatory step right now.
Question: which reference platform? And how to choose it?
Should we go with a LTS style? Using a 10-years support like what Redhat does is appealing but you may skip important technology evolutions. Ubuntu (well even if I personally dislike it) has a shorter support timeline for LTS (but some discussions are made to extend it to 10 years).
Do we need (for Natron itself) sort of care (really! it’s an important point)?
I am sure this opinion will be reviled by a few, but why not target one of the new packaging formats? Natron is already packaged up for flatpak. Snap shouldn’t be much harder and Canonical would likely help you with the initial packaging if you run into issues. @probonopd would probably chip in for an AppImage as well. This makes “distro support” less of an issue.
