NVIDIA Shares Wayland Driver Roadmap, Encourages Vulkan Wayland Compositors

[oiaohm]

I actually vaguely remember the attempt to supplant Beep Media Player with BMPx (and the name BMPx makes sense as a follow-up to BMP) and I wouldn't have known about Youki because I lost interest during the BMPx era.

So, given that I have my memory and a site agreeing that Youki came later, I'm calling [citation needed] on yours.

https://software.fandom.com/wiki/Youki

There was a line here you missed.

Youki is the current media player of the MPX Project. Previous media players produced by the team were Beep Media Player, BMPx, and the never officially released audiosource.

Beep media player and BMPx and youki come from the same development team.

That site has a false hood that a person can fall for by the wording.

Youki shares virtually no code with the older Beep Media Player or BMPx and was instead written from scratch.

You can pull the source code to early Youki, Beep and BMPx out of debian snapshots there are 100 percent identical source files between all 3.

Yes the words "sharing virtually no code" is not the same "sharing no code". Most of Youki code was rewritten from scratch but not all of it.

https://de.wikipedia.org/wiki/Beep_Media_Player#/media/Datei:XMMS_family_tree_timeline.svg

Yes old time lime used in the german section of the wikipedia is clear "mostly rewritten" that was the original Wikipedia wording not the later deceptive "virtually no code". Also this timeline was based on what the parties were saying not checking the source code if it matches.

Yes I was getting it wrong its BMPx and audacious are in the same time frame. Looking at the source code files from BMPx appear in audacious that don't appear in the prior beep. So audacious is not 100 percent based off Beep original beep there are fragments of BMPx and these fragments are older than audacious and are authored by one of the developers who started audacious..

My mind was thinking of Beep, BMPx and Youki basically being major revisions of the same thing. What they are in reality thinking they have the same lead developer and they have small amounts of common code. By the files you find in audacious the dispute started with BMPx and this first to appear in BMPx code remains in the early versions of youki at debian.

What MPX Project doing is they were having issues lets so rename the project so users think we are a new project so don't hold prior issues against us or go looking for prior issues. Yes completely renaming the project to mark major versions instead of just bumping a major version number. This does make the history messy.

[ssokolow]

So was I.

There are problems with this timeline. Youki predates Audacious and another problem is a Youki early patches is in Audacious code base. So Audacious did not fork from Beep but in fact forked from early Youki.

My memory of things agrees with this snippet that software.fandom.com claims originates in a now-deleted Wikipedia article:

Youki is the current media player of the MPX Project. Previous media players produced by the team were Beep Media Player, BMPx, and the never officially released audiosource. Youki shares virtually no code with the older Beep Media Player or BMPx and was instead written from scratch. The only component kept in its basic outline is the BMPx-originated GStreamer-based playback engine, which has since been rewritten and refactored.

I actually vaguely remember the attempt to supplant Beep Media Player with BMPx (and the name BMPx makes sense as a follow-up to BMP) and I wouldn't have known about Youki because I lost interest during the BMPx era.

So, given that I have my memory and a site agreeing that Youki came later, I'm calling [citation needed] on yours.

[oiaohm]

I was around during that period.

So was I.

XMMS got forked because the codebase everyone cared about was stuck on GTK 1.2 while "XMMS2" was more of an MPD clone. (Think Perl 5.x vs. Perl6/Raku) That GTK 2.x fork was called Beep Media Player (BMP or BeepMP for short) and it was horrendously crashy. Audacious forked from Beep Media Player because the Beep devs were incompetent at making a GTK 2.x media player that didn't crash every five minutes.

There are problems with this timeline. Youki predates Audacious and another problem is a Youki early patches is in Audacious code base. So Audacious did not fork from Beep but in fact forked from early Youki.

Yes a lot of people who don't look at the Youki vs Beep vs Audacious code based don't wake up that Audacious not based direct off Beep.

I'd never heard of Youki back in the day and, judging by the summary I read now, it sounds more like Milosz Derezynski (there's a name with some "tantrum-throwing incompetent" memories behind it)

You remember the person right. You can see exactly how he managed to screw up development for the early Audacious developers so creating fork Audacious so creating doom for the Youki project he was managing.. Banning a stack of users from github for no particularly good reason as godot did is tantrum throwing incompetence. Youki forum back in the day did the same thing with some early future Audacious developers who were working on youki at the time for talking about crashes because this could be bad PR....

Youki one simple action lost a large number of it developer core and it marketing core. Yes banning people for talking about the crashing issues.

There are other examples when you go looking where the main project harms development process sometimes its like Youki a fairly fast killing of the organ project (5 years roughly). Other cases it takes a few decades for the long term effects to happen.

Its not wise to presume you can mess up open source project development and not have to pay a price for it.

Yes ssokolow there are a lot of applications that people believe they were developed in project 1 then project 2 that in reality project 2 was developed first and then some issue in development happened resulting in a split with project 2 creating project 1. Yes then project 2 ceases to exist. Since project 1 is the winner they write the history as if they never were fork off the project they defeated. This is major source of the false myth that the main project can do bad things and never loss most of the time when in reality the main project loses more often than wins. in the cases where the actions disrupts development even for less than 2 percent of the developers in the project.

[wertigon]

Yes without the disruption to development redot chances would look like your numbers. Due to distrupting development and the effects that causes its 1/3 Godot remains dominate. 1/3 redot end up dominate. 1/3 both die. Both equally successful is the rare outcome still. This is why you don't want projects getting political in their source repository mainintainership.

That is your take then. Let's agree to disagree here, it doesn't really matter to me whether the thing I use to make games is called redot or godot in any case. It is a wait and see situation.

Song of the day: I love It by Icona Pop

[ssokolow]

https://en.wikipedia.org/wiki/XMMS

This is because you have not looked at the history where equal thing happened. Youki, vs Audacious, Yes this was a case that action of upstream with poticial things interfered with Development. Yes Audacious, is the fork.

I was around during that period.

XMMS got forked because the codebase everyone cared about was stuck on GTK 1.2 while "XMMS2" was more of an MPD clone. (Think Perl 5.x vs. Perl6/Raku) That GTK 2.x fork was called Beep Media Player (BMP or BeepMP for short) and it was horrendously crashy. Audacious forked from Beep Media Player because the Beep devs were incompetent at making a GTK 2.x media player that didn't crash every five minutes.

I'd never heard of Youki back in the day and, judging by the summary I read now, it sounds more like Milosz Derezynski (there's a name with some "tantrum-throwing incompetent" memories behind it) was trying to shed Beep's reputation for crashiness by starting over and keeping nothing but the GStreamer backend... no wonder nobody cared since that would make it Just Another Media Player™ from someone with a not-great track record, with a UI and plugin ecosystem even less related to XMMS than QMMP (an XMMS and now Audacious clone written before Audacious started adding a Qt-based frontend and deprecating the GTK-based one).

It had nothing to do with politics and everything to do with Milosz Derezynski being incapable of meeting market demand on technical grounds. (Hell, I ran XMMS, then BMP, then Audacious, and that's why I switched. Audacious was GTK2-based XMMS without the crashes.)

[oiaohm]

Sure, anything is possible in the land of fairies. And the probabilities of that happening over a political spat such as this one?

Status quo maintained: 75%
Redot actually making a dent: 20%
Both die: 4%
Both successful: 1%

The chance is not zero, but not very big either.

https://en.wikipedia.org/wiki/XMMS

This is because you have not looked at the history where equal thing happened. Youki, vs Audacious, Yes this was a case that action of upstream with poticial things interfered with Development. Yes Audacious, is the fork.

Its even bet at this point of Redot replaces godot or not. There are two more options I did not include that is godot die or redot die alone. Yes godot is higher to die because they are the one that the the development distributing action.

Status quo does not have large hold in open source world. Libreoffice replacing Openoffice Libreoffice is the fork. Maradb replacing most places mysql is used Maradb is the fork. There is a long list the fork has the advantage or is equal to the parent project that is the way it is when this stuff happens.

This stuff happens I am referring to action that effects development. A pure political for Like the Gimp one these always fail remember this never disrupted gimp project development chain. Banning users from github because something got tits up on X/Twitter end up effecting development.

Yes without the disruption to development redot chances would look like your numbers. Due to distrupting development and the effects that causes its 1/3 Godot remains dominate. 1/3 redot end up dominate. 1/3 both die. Both equally successful is the rare outcome still. This is why you don't want projects getting political in their source repository mainintainership.

[wertigon]

Sure, anything is possible in the land of fairies. And the probabilities of that happening over a political spat such as this one?

Status quo maintained: 75%
Redot actually making a dent: 20%
Both die: 4%
Both successful: 1%

The chance is not zero, but not very big either.

[oiaohm]

Ok, so there are two possibilities for a YOSO dev that don't give a fuck about FOSS politics:

1. redot becomes the new main fork. Great. I switch to redot. Problem solved.
2. redot becomes the latest niche fork. Great. I keep using godot. Problem solved..

No there is 4 possible and the 4 forth we really don't want to happen.
3. redot and godot end up equally success full and there is enough fund in the whales to support this YOSO developers choose engines now based on what one has the feature they want and both engines will over time come different engines..
4. redot and godot both go under due to lack of funds. These both now come unmaintained and die. Because there were not enough whales to support both existing and the whales funds split in two where not enough to fund individual project. Yes there can be loss of some whales that where there before because fighting breaks out between the two projects time goes forwards.

There is not a unlimited number of whales to keep open source projects going and if this is split too many ways you see the all projects die quite a bit. Yes 4 has happened quite a few times and is more common to happen than 1 2 and 3 combined with other projects. Its number 4 why projects so be very careful banning people in number that could trigger a fork because the fork may not beat the project it forked off but project may not survive the fork existing either due to funding issues.

[wertigon]

Except this is not a Devuan. This like go-oo/libreoffice vs openoffice.

Ok, so there are two possibilities for a YOSO dev that don't give a fuck about FOSS politics:

1. redot becomes the new main fork. Great. I switch to redot. Problem solved.
2. redot becomes the latest niche fork. Great. I keep using godot. Problem solved.

There is no real reason to stick around and there is no real reason to switch. From a biz perspective it is a toss-up. Right now, just keep using godot and let redot do their thing. Maybe it will be good, maybe not. Honestly IDGAF.

[oiaohm]

(Specifically, cite your sources that they're actually whale customers and not just angry whiners.)

https://github.com/Redot-Engine/redot-engine/pulse

Some of them appear in the 25 authors now. So its not just angry whiners.

https://github.com/godotengine/godot/pulse

Yes godot core development count only runs around 10. They are not a large core team.

This. Also, even if the redot folks are former "whale customers" of godot, and I find that doubtful, how many whales are we talking here? My bet is, < 5% of all godot whales.

So let's give it 6 months of redot and see how it goes. At best, I predict Devuan levels of success. Time will tell.

Except this is not a Devuan. This like go-oo/libreoffice vs openoffice. Devuan not using systemd causes them a lot of problems. There are lot of item they cannot import from Debian.

go-oo yes predecessor to libreoffice was always able to import all the new feature of OpenOffice. So lets say its 5 percent. You can apply a 20/80 here. 20 percent of the resources goes into maintaining what is different the other 80 goes into adding new features. So that means the 5 percent loses 1 percent maintaining theme thing and porting code that does not exactly match but the project over all development is 104% compared to Godot 100%. This comes a slow death by thousands of cuts to the core project. Yes at first this looks like a minor problem.

Why the 80/20 does not apply to Devuan name one new feature Devuan has that could be useful to majority of debian users. You will be going. Then do the same with the gimp political fork.

https://www.redotengine.org/news/release-4-4

Notice here that 4.4 has a feature in that picture that development branch godot does not have.

How do you tell quickly if a fork is angry whiners or a possible serous threat to a core project? Simple fork adding features that can be useful to majority of users that the core project is being slow to add or not adding to the core project. Pure political forks don't have this so they die.

When it come to long term Open source project health minorities can be quite dangerous. Many open source projects have been over time defeated by forks that are able to keep on taking the core project and added small amount of extra.

Redot would not be at the point is now if the godot moderators had not done the stupid.

Yes do look at those stats again up the top. As well as pulling in godot mainline redot is in fact merging more on top of that. Redot is not just a political fork. Redot is a fork due to development issues that including people banned without good reason but is not the only godot problem. The banning gave Redot the funding kick start it need.

wertigon you said 6 months. History of forks killing parent project says this could be a bleed out over a decade. That only got a foot hold because godot moderators over reacted badly and did not take quick corrective action to maintain trust.