Project maintenance

[vkhodygo]

It looks like the project is effectively unmaintained, the question is what to do to resolve this.

I'd like to hear what other contributors think:
@vovodroid @timschneider @legend069 @julianschill @nanoplane @MrRKernelPanic @bwnance @Aviator-Coding @aelnagger @RealDeuce

It is obvious to invite @supermerill as well.

Do not hesitate to mention other people to participate in the discussion.

[W8BSD]

Basically, a new maintainer needs to step forward, and they can really do whatever they like. The last option leaves @supermerill as the implicit maintainer, so he's really the only one that could make that happen regardless of what we want.

I would prefer to see it set up as a community owned project (group or whatever github does) instead of a personally owned project so if the maintainer needs to change again in the future, it can be seamless and not involve pointing to a new repo.

[legend069]

I'll agree with you on this.
i would prefer a community group owned project, with x members that would communicate with features/bug fixes they're working on.
users see "no updates" and think the software is dead and move on to find other software.

from my perspective i would like super slicer to live up to the "super" in it's name and have all the features and options for users to fully the advantage of.

[vovodroid]

A week ago Merill was active in PR discussions, so I hope he'll continue SS support. From technical point of view it seems that SS is quite diverged from Prusa, thus keeping it updated to original could be not trivial task.

[timschneider]

I agree with the difference to prusa - but to me - as a heavy user of superslicer - it seems, that superslicer/supermerill did a great work in pushing the slicer more into the technical area - far away from the shiny cura. This is the reason why I love superslicer, because it makes it easy and reliable for me to create technical 3d prints. But most of the "advanced" features are already migrated to prusa again - e.g. bridge/overhang threshold for speed/flow and cooling. What is missing for me is:

• brim ears, and
• filament shrinkage
• print volume scaling (prusa limit of z<1200mm)
  Maybe it is worth to discuss the possiblity of starting over again with prusa 2.6 as a new basis and migrate all the missing features from superslicer into a new branch / major release - so that super slicer can again benefit from the effort prusa is doing and we can benefit from the advanced features. As far as I understood Josef Prusa correctly in an interview (can someone remember where?), the Prusa Slicer is not intended to be developed by the community.

[vovodroid]

migrate all the missing features from superslicer into a new branch / major release

It's not a trivial task, as many internal structures are heavily modified and refactored in SuperSlicer.

[vkhodygo]

A week ago Merill was active in PR discussions

The fact this project needs more hands is still there.

[aelnagger]

My impression is that there are a couple regular contributors to PS who are likely employed by Prusa to develop features for it. From a logistical standpoint, one person is not going to be able to keep up with that in their spare time.

Ultimately I think it's within the spirit of open source for folks to fork SS if they want. In all of this I don't know what @supermerill thinks about giving more contributors ownership of the current project, and I think that would be useful information for the community to have.

[aelnagger]

Gentle ping to @supermerill now that you have the ability to work on this project full time. I think a lot of people are interested in helping and ensuring that this isn't too much of a burden for you to bear alone.

[supermerill]

Hi
I'm open to setup a community repository.
I think there is two option:
. using the slic3r name & repository, merging the communities together:
. There is a little community over slic3R, with @lordofhyphens as the main maintainer.
. I already use the slic3r-profile repository for profiles.
. I already have a slic3r skin.
. What's needed is to make more documentation and testing. I'm currently working on the testing part, fixing them and writing more of them.
. there is an irc channel (Libera network, channel #reprap) to talk about that.
. creating a new organisation
. I think it's only viable if the first option isn't possible.

Then, there is the money issue.
Currently, the donations are directed to me.
If we create an organization, with multiple contributors, how do we split the donations?

[DoubleStrike]

I can contribute some ideas to your last question. That would be pretty straightforward, I think. A good benchmark would be to use a scaled-down version of something like the Blender Institute. WAY, way scaled down.

Essentially, have all donations go into a pool, and then development tasks would be assigned a dollar value based on time/complexity. It would require some true-up at the end of each quarter for example, but it'd be a straightforward way to manage it. It would require someone to validate time estimates, but multiple contributors could cross-check each other on that. If all the money is handled transparently, then no bad actors can take advantage.

Contribute a lot of major work/time/documentation, get a bigger piece of the pie. Contribute less, get less.

[supermerill]

Yes, good idea for features.
For unit testing, this can also be a kind of feature.
But for bug correction, it's a bit more difficult.
It happens to me to uses many hours to find the root cause of a bug to fix it by modifying only one line in the end. Should the difficulty be awarded afterwards? Or the bugs are handled another way? What if a contributor succeed to implement a feature but creates many many bugs (I do that sometimes)?

[timschneider]

Maybe this can be address with a review process.

A constributor needs to provide the following in order to get the revenue

• a description of what the code should do as a comment for the main part of the code
• the code / changes itself according to the code guidlince
• unit tests of the code in order to check if the code is doing what it is intended to do and to improve regressions (positive tests)
• (optional) unit tests of the code to check if the code can handle wrong input / misuse (negative tests)
• the code must be approved / signed by at least three different constributors

only if all requriements are fullfilled, the constributor is awarded. (even if there are bugs in the code / as this is the risk of the organization after the full process).

[vkhodygo]

Now that you're back it's up to you what to do next. All I wanted was regular code maintenance which becomes difficult when there is only one person with access to the repo.

Regarding funds, other replies seem to be reasonable. OSS is not the most profitable business, it heavily relies on the community, however, some people deserve to be paid due to the amount of work they do.

[DoubleStrike]

I think the key is transparency. The only way to achieve any level of equity between multiple people is just to be direct and open. Usually a project owner would have final voting power to break a tie, but all those things being done in the open generally keeps bad feelings away as long as possible.