Are changes made in prusa-slicer incompatible with upstream? (economical and code quality concern)

[Kreyren]

Are there any advantages to using prusa-slicer over slic3r or is prusa-slicer just a hate fork where author didn't bother to merge the changes upstream?

[supermerill]

where author didn't bother to merge the changes upstream?

Why merge upstream?

[Kreyren]

Why merge upstream? -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032720204)

Because of the fundamental philosophy of open-source to avoid reinventing the wheel with needless functionality and over/under engineering that is dependent on incompatible code across forks?

[Kreyren]

Like i am not blaming prusa for branding and having an all-in-one solution, but from reading the code it seems that it would be better in terms of resource utilization to merge the changes upstream and just sync fork with branding patches.

[supermerill]

Because of the fundamental philosophy of open-source to avoid reinventing the wheel with needless functionality and over/under engineering that is dependent on incompatible code across forks?

For the "reinventing the wheel", I don't understand what you mean. If you want to add something to slic3r and PS already did it, you can copy-paste their code if you want.

For "over/under engineering" I really don't understand what you mean. If you don't publish pull requests, you are over-engineering things?

For the "incompatible code", that's one of the reasons they had to fork instead of continuing to submit pr. They wanted to change things.

Prusa can't wait for the mainline to implement stuff, so they do it their way on their fork. And the mainline (maintained by a single user in his free time) can't keep up with a full team of dev paid full-time. Their code isn't accepted in the mainline because it's not backed by unit tests, or it's just too many too quickly, or it's not compatible now they switched some libs, and switched from perl to c++.

You can't really "merge upstream", whatever "philosophy of open-source" means. You can pick up some things (and it's not really the job of prusa as they don't know what's wanted), or replace everything with prusaslicer and rename it.

Also, Prusa is a company, they won't spend days (money) to create pr for ... what? "philosophy of open-source" ? "philosophy of open-source" won't pay salaries.

Note: I'm not affiliated with prusa in any way, it's just my view as an open-source dev.

[supermerill]

merge the changes upstream and just sync fork with branding patches.

check the merill-merge branch here

[Kreyren]

For the "reinventing the wheel", I don't understand what you mean. If you want to add something to slic3r and PS already did it, you can copy-paste their code if you want. -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

The simplest scenario i can think of would be a for-loop that outputs a Hello world e.g.

for i in {1..5}; do
  printf "%s\n" "Hello, world!"
done

where forking such code might introduce additional functionality such as:

for i in {1..5}; do
  printf "%s\n" "Hello, world!"
  printf "%s\n" "Hello, underworld!"
done

The problem begins when multiple forks start to introduce the same functionality in a way that is not cross compatible:

# Fork A
for i in {1..5}; do
  printf "%s\n" "Hello, world!"
  if "$specialFeature" = true; then 
     printf "%s\n" "Hello, underworld!"
  fi
done

# Fork B
for i in {1..5}; do
  printf "%s\n" "Hello, world!"
  if "$CoolFeature" = true; then 
     printf "%s\n" "Hello, underworld!"
  fi
done

as the work now requires to rework the if statement logic in order for both forks to be able to use it thus adding a workload which can be avoided by submitting the changes to upstream for both parties to benefit from the work.

Note that this scenario is perfectly fine if the two forks are both implementing a functionality that is workflow-oriented or otherwise not compatible with the original project, but from skimming through the code of both Slic3r and prusa-slicer i don't see this being the scenario.

For "over/under engineering" I really don't understand what you mean. If you don't publish pull requests, you are over-engineering things? -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

Using the simple code above:

# Over-engineering
for i in {1..5}; do
  printf "%s\n" "Hello, world!"
  if "$CoolFeature" = true && if_stars_are_aligned() && true == true; then 
     printf "%s\n" "Hello, underworld!"
  fi
done

# Under-Engineering
for i in {1..5}; do
  printf "%s\n" "Hello, world!"
  if true; then 
     printf "%s\n" "Hello, underworld!"
  fi
done

Prusa can't wait for the mainline to implement stuff, so they do it their way on their fork. -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

That is not a valid excuse for the highlighted issue as such situations are usually addressed by granting a merge permissions e.g. CODEOWNERS on github.

Practical example could be the GNU project e.g. GNU Guix.

Their code isn't accepted in the mainline because it's not backed by unit tests, or it's just too many too quickly, or it's not compatible now they switched some libs, and switched from perl to c++. -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

I agree that sacrificing on the code quality which would make the changes not mergable upstream is a valid reason for them to not be included, but the usual solution to this problem would be to make a new branch where these features can be worked.. Rushed code is not really helping anyone in open-source setting and usually requires exponentially more resources to maintain over the time.

EDIT: Alternatively in my development i follow the practice of code tagging e.g.

# FIXME-QA(Krey): Requires test
printf "%s\n" "Hello, world!"

Ideally these tags would be excluded from the software build on demand, but that is not always an option especially in C++ which from my experience makes it too resource demanding to implement feature-gates due to the over-complication of cmake.

Also, Prusa is a company, they won't spend days (money) to create pr for ... what? "philosophy of open-source" ? "philosophy of open-source" won't pay salaries. -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

Open-source and Free Software in this situation is generally more economical for a for-profit company to follow. So it will pay salaries especially if you are using the software solution as a critical part of your business plan and rushing the code while ignoring code quality will only hurt economically will eventually end up not reliable in the production settings.

Note: I'm not affiliated with prusa in any way, it's just my view as an open-source dev. -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

I recommend you to get familiar with Free Software development and technoliberalism https://en.wikipedia.org/wiki/Technoliberalism.

What you said are valid arguments for proprietary open-source development following the definition of an Open-Source Initiative, but invalid for Free Software Development (as Slic3r is using a Free Software License not non-free open-source) following the definition of The Free Software Foundation where the economy of software development is already addressed, see an article by The Free Software Foundation Europe on the subject https://fsfe.org/freesoftware/sustainability/sustainability.en.html.

EDIT: And it's also possible to restrict the right to use and distribute until the cost of the development is paid e.g. what Ultimaker Cura seems to be doing by allowing plugins for AI smart infill e.g. SmartSlice (https://www.tetonsim.com/smart-slice-for-cura) assuming that the removal of restrictions for use and distribute are enforced after the development cost is paid to avoid situations such as allegedly Purism Librem 5 [https://git.dotya.ml/kreyren/kreyren/issues/13] so that the developers contributing an unpaid work through "the right to improve" to the solution are compensated for their work.

check the merill-merge branch here -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032821150)

Context?

[supermerill]

Then do it.

[Trellian]

@supermerill Agreed.

@Kreyren , lighten up dude. Someone is going way out of their way to give you something for free. In the spirit of "Free Software development and technoliberalism", develop some empathy, and drop the not even so passive passive-aggression. As @supermerill says, if you feel so strongly about it, jump in and contribute. And be nice about it. These people don't owe you anything. In fact, it's the other way around.

[Kreyren]

@Kreyren , lighten up dude. Someone is going way out of their way to give you something for free. -- @Trellian (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032892416)

You missunderstood the definition of Free Software.. it's not Free as in Gratis, but Free as in freedom implying liberalism not socialism, economy and resource utilization remains critically important in the subject.

if you feel so strongly about it, jump in and contribute. And be nice about it. These people don't owe you anything. In fact, it's the other way around. -- @Trellian (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032892416)

I do feel strong about it thus why i raised it here as i am not in position to make the proposed changes due to the lack of permission to manage the repositories while prusa's employees are able to perform this change more efficiently as they are familiar with the source code.

develop some empathy, and drop the not even so passive passive-aggression.-- @Trellian (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032892416)

I am not aware of being passive-agressive, but i do recognize that the title is inapropriate to the development of the discussion.

[Trellian]

Thank you for re-evaluating your stance, it shows maturity.

Yes, I know Free is not as in Gratis, in principal, however you are also getting the benefit of hundreds or thousands of personal hours from a few real people involved who are giving up their time and skills and donating it to society. That is Gratis, and should be respected. That is also a valued tenet of liberalism.

Let us now get on with a constructive conversation.

[Kreyren]

Yes, I know Free is not as in Gratis, in principal, however you are also getting the benefit of hundreds or thousands of personal hours from a few real people involved who are giving up their time and skills and donating it to society. That is Gratis, and should be respected. -- @Trellian (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032924607)

I agree that it should be respected and i am not aware of doing anything to disrespect their effort, but this is not gratis these contributions are submitted for software freedom sake and anyone is free to establish a for-profit model off of it like prusa research, a.s. is doing.

Do not confuse this effort with technosocialism where developers are submitting patches for the sake of society for gratis which is not concerned about economy and so far proved to be unsustainable for a long-term software development.

[Kreyren]

To clarify the point i am trying to make here is that standalone forks with changes that are mergable upstream are:

1. not economically sustainable/efficient in a long term
2. sacrifices on features for users of both solutions (and allegedly in this case on code quality due to the lack of unit tests in PS)
3. are inefficient in terms of brainpower (FSFE's term)

So if the changes are compatible with the upstream then they should be submitted here and the work coordinated to enable sufficient quality assurance and maintenance.

[supermerill]

These three points are only valid if the upstream is alive. Slic3r is mostly stagnant with a very low level of contribution for years.

Since then, PrusaSlicer has migrated the whole GUI from perl to c++. They have added many libraries. Then updated almost all the codebase.

There's not that much of the current slic3r code still in the PrusaSlicer.

Context?

It's the branch where I update and "merge" against prusaslicer. There is still some feature of the legacy slic3r that aren't inside. Feel free to help me add them into it.

[Kreyren]

These three points are only valid if the upstream is alive. Slic3r is mostly stagnant with a very low level of contribution for years. -- @supermerill (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032951931)

I see, so why not surrender the maintenance to PS and set this project as obsolete by PS? So that none is inclined to contribute to it when it's unmaintained and focus the development on the maintained fork?

[Trellian]

Ai. Freedom of speech and freedom of development.

I see, so why not surrender the maintenance to PS and set this project as obsolete by PS? So that none is inclined to contribute to it when it's unmaintained and focus the development on the maintained fork?

Because there are many thousands of people who use it, and people that want to contribute, know the technology, perhaps don't want to get into quite so much C++, respect the legacy, have been using it for years, don't want to abandon it, don't want to contribute specifically to one company's financial gain, believe in free unfettered speech, like contributing to something they see as free and unfettered. I feel like you are missing the point. If you don't want to use this software, then leave it be. People like @supermerill see the value in the underlying software, have spent thousands of hours fixing and upgrading in their own version (which is what GitHub is about), but can not compete with a team of paid developers. Contributors are in no way obliged to maintain or align with upstream versions. It is sometimes impossible or unfeasible (unless you are getting paid for it). Nevertheless, he has added an amazing amount of value to real people's lives. If you don't like the branch, perhaps conside find another one that more closely aligns with your values. Or, just jump in and contribute. There will be many thousands of users who would appreciate your input.

The fact is, the branches are not realistically mergeable at this point. So in the natural order of things, a separate branch is starting to evolve. You are free to leave it or embrace it.

[Kreyren]

If you don't want to use this software, then leave it be -- @Trellian (https://github.com/slic3r/Slic3r/issues/5127#issuecomment-1032971763)

For context i didn't know that PS is fork of slic3r until now so mainly i wanted to know if there is a usecase for it in comparison to PS to have options for my designs.

[lordofhyphens]

Yes, most changes made in PrusaSlicer are not easily merged with upstream. Prusa's team started their fork because the previous maintainer was hard to get ahold of and then made a bunch of changes on their own and Prusa has no business interest in trying to incorporate them upstream and I don't have the time or personal funding to do it either (being one person with a full time job).

What I do need is to get documentation updated so that the merill-merge branch (@supermerill is a saint btw) can become the main branch and get us back in a position where it isn't a huge issue again to share code.

Unfortunately I also expect Prusa's team to continue running on their own (which they are permitted to do so long as they abide by the GPL).