Wayland Gets Forked


Recommended Posts

This is getting stupid. Why can't we just work on one ****in thing!?!?

Explanation:

http://www.phoronix....ston_fork&num=1

don't worry, its just one random dude's fork and its not going anywhere and won't detract from the upstream wayland project in any way. The guy was being a douche in the wayland irc and mailing list and got banned, so he created a rage-fork and is now crying about his innocence and promoting his fork on phoronix :p

  • Like 1
Link to comment
Share on other sites

This is getting stupid. Why can't we just work on one ****in thing!?!?

Ditto this.. would rather just have one that works very well versus a bunch of project forks that can't agree on anything and wind up just making things muddled. It's the million-and-one-sound-systems all over again. Sometimes being open source can bite you on the butt.

don't worry, its just one random dude's fork and its not going anywhere and won't detract from the upstream wayland project in any way.

Agreed; Wayland's gotten quite a lot of notice. A "rage fork" (lol) probably won't last very long.

Link to comment
Share on other sites

don't worry, its just one random dude's fork and its not going anywhere and won't detract from the upstream wayland project in any way. The guy was being a douche in the wayland irc and mailing list and got banned, so he created a rage-fork and is now crying about his innocense and promoting his fork on phoronix :p

Ha! That's funny! I was thinking the same thing. Does he really think graphics card manufactures are willing to support X.org, Wayland, Mir and now his project? LOL!

But still--I'm getting pretty tired of redundant buggy pieces of software. Why can't developers get together and create one awesome piece of technology that suits everybody's needs? This is probably one of the greatest short comings of FOSS, imo.

Link to comment
Share on other sites

don't worry, its just one random dude's fork and its not going anywhere and won't detract from the upstream wayland project in any way. The guy was being a douche in the wayland irc and mailing list and got banned, so he created a rage-fork and is now crying about his innocence and promoting his fork on phoronix :p

the problem with open software. instead of having to work together people can just go off on their own tangents instead of contributing.

though in this guys case, he'd probably be kicked off the project if it hadn't been open anyway so no big loss.

Link to comment
Share on other sites

don't worry, its just one random dude's fork and its not going anywhere and won't detract from the upstream wayland project in any way. The guy was being a douche in the wayland irc and mailing list and got banned, so he created a rage-fork and is now crying about his innocence and promoting his fork on phoronix :p

Yep

The only reason this is "news" is because the guy wrote the article and had it posted, nobody cares in the scheme of things.

Link to comment
Share on other sites

the problem with open software. instead of having to work together people can just go off on their own tangents instead of contributing.

But people going off on their own tangents wouldn't be contributing anyway. On OSS they fork while on closed source projects they might start the same thing over from scratch or just think "screw it" and go watch some TV.

Link to comment
Share on other sites

But people going off on their own tangents wouldn't be contributing anyway. On OSS they fork while on closed source projects they might start the same thing over from scratch or just think "screw it" and go watch some TV.

now if you read the whole post that was covered.

the thing is in an organized project, most of these people would be tld to stop dicking around and do what they're supposed to and do it.

Link to comment
Share on other sites

now if you read the whole post that was covered.

the thing is in an organized project, most of these people would be tld to stop dicking around and do what they're supposed to and do it.

Assuming Wayland is not an organized project (which I don't know if it is, altough I guess it should) even if it was and someone told this guy to stop dicking around he'd just most probably get out of it, OSS or not.

The most likely reason he would want to accept orders that don't align with his own interests is if he was being paid, which again would have nothing to do with the project being OSS or not.

In this specific case, anyway, whether he forks or just leaves is largely irrelevant, considering that his fork is going nowhere on it's own.

Link to comment
Share on other sites

whether he forks or just leaves is largely irrelevant, considering that his fork is going nowhere on it's own.

well, its entirely depend on how he managed the fork,

Webkit for example is a succesful forks from some obscure linux browser layout-renderer.

Link to comment
Share on other sites

well, its entirely depend on how he managed the fork,

Webkit for example is a succesful forks from some obscure linux browser layout-renderer.

But Webkit wasn't forked by one lone bitter guy who apparently had been banned from the project channel for behaving like a dick.

(Being part of the KDE project I wouldn't call KHTML "obscure", though).

Link to comment
Share on other sites

well, its entirely depend on how he managed the fork,

Webkit for example is a succesful forks from some obscure linux browser layout-renderer.

webkit was an apple fork and had apple behind it. if one random person had forked khtml instead of apple it would have gone nowhere.

Link to comment
Share on other sites

(Being part of the KDE project I wouldn't call KHTML "obscure", though).

The last time I played with Konqueror you could chose to use either KHTML or Webkit to browse with. So you are right, not exactly obscure.

Link to comment
Share on other sites

3tlzrm.jpg

This got way more publicity than it should have. Like Viper said, it was a rage fork (stealing this term btw) because the guy was acting like a douchenozzle and got himself banned. It is worth noting that he does have valid concerns, but his approach is being widely criticized as wrong, and he's generally responded with large amount of name calling and profanity without really considering why he got himself into this situation in the first place.

the problem with open software. instead of having to work together people can just go off on their own tangents instead of contributing.

I don't want to get into an ideological debate here, but forking is by far one of the best things about OSS.

  • It gives you the ability to make a specialist version of a piece of software, out of the scope of the original project (see: The Cedega fork of WINE, which specialises WINE specifically for games).
  • It allows a project to be detached in the face of uncertainty about the direction of the project (see: LibreOffice from OpenOffice, MariaDB from MySQL, which were forked after concerns about Oracle's intentions for the project)
  • It allows control of a project to be transferred when a project dies (see: KompoZer from the dead Nvu project, TrueCrypt from the dead E4M project)
  • It allows development to be isolated from the trunk project until the trunk project is happy to integrate the changes (see: Android mods to the Linux kernel, EGCS into GCC)
  • It allows variations of a project to be created to cater to specific audiences. (see: Waterfox from Firefox, SRWare Iron from Chrome)
  • It allows developers to continue a project in a different direction in the event of difference of opinion (See: Wayland here, OpenBSD, Joomla, MATE, and a great many others)

I see all these things as positive, although the latter is the most controversial since it can lead to fragmentation. It often doesn't though, since forks can often be merged back into the main project (or replace it entirely) if the fork is deemed to be a significant improvement to the project. None of these things are possible with proprietary software.

Link to comment
Share on other sites

None of these things are possible with proprietary software.

Albeit rarely anyone working on proprietary software acts like a juvenile all-knowing d*ck in project meetings. They have a deadline often set by clueless feckers, a budget to squander on new chairs and desks and a general idea of what cannot possibly be done given those two boundary conditions. I see that as positive thing. Ok, just kidding...

All I wanted to say in my pointless defense of proprietary was "you cannot fork a paycheck".

Link to comment
Share on other sites

All I wanted to say in my pointless defense of proprietary was "you cannot fork a paycheck".

"Forking a paycheck" is an issue with paid for development, not specifically proprietary (ie. Redhat devs surely can't fork a paycheck either).

There's a lot of proprietary freeware out there developed for free. You don't hear about forks of that, projects either go on or vanish as soon as the developers lack time or lose interest.

Link to comment
Share on other sites

Proprietary paid software is generally not abandoned as long as the software serves a purpose or in other words, has a customer base.

FOSS projects thou, can and often get abandoned because the dev goes tired of the project or just don't care about it anymore, despite there being a huge interest.

This sometimes happens to small one man proprietary projects to, generally free one, as the def simply don't have time or interest any more. And a lot of the time you have the league of FOSS gentlemen coming and pestering him to release the source for someone else, and they never take no for an answer, we've seen it on this very forum.

As for optimized forks. I would argue that a most if not all of those could have been avoided by putting in more work in the original project and coding it properly to handle different scenarios and situations. The WINE example is one such good example where better, more optimize and modularised coding would have yielded the same result in the original project, with less resources wasted on forked dev.

Link to comment
Share on other sites

All I wanted to say in my pointless defense of proprietary was "you cannot fork a paycheck".

Very true, I agree. As HawkMan suggested as well, some of the reasons for a software fork are irrelevant for a proprietary project. For example I don't think there'd ever be a case where a project would be forked through management issues.

That said, there are cases where Forking a piece of proprietary software could be desirable for a customer/user.

Consider Windows XP. XP is due to go out of service next year, and there's probably going to be some small subset of people and companies that are unable (or unwilling) to upgrade, and would rather stick with Windows XP on an archaic IT infrastructure than spend the up-front cost of having to upgrade. If Microsoft were to allow people to fork XP, people could continue creating patches for it long beyond Microsoft's support period, but because they can't, these people are likely to simply continue using an out of date OS until the hardware dies.

That example is a bit (okay, a lot) facetious, but it illustrates my point. It would never happen though because it would be a drain on Microsoft's profits (like you said, can't fork a paycheck), so there's no incentive to do it, and instead they encourage people to upgrade.

The WINE example is one such good example where better, more optimize and modularised coding would have yielded the same result in the original project, with less resources wasted on forked dev.

Surely it is because WINE is well coded with a modular structure that Cedega can exist at all? Cedega doesn't really optimize WINE (as is my understanding at least; they don't release their contributions or send them upstream), they simply specialise it purely for games (different interface, more of DirectX implemented, etc), whereas WINE aims to be more generic and less focused on a single use-case.

It's all well and good saying "As for optimized forks. I would argue that a most if not all of those could have been avoided by putting in more work in the original project and coding it properly to handle different scenarios and situations.", but that sort of assumes that these projects have massive budgets and the ability to predict the future.

Link to comment
Share on other sites

But all that work, and more of it is already being done by forking. Each fork has overheads. This means if they instead had focus on just the main WINE project, and added a game mode to that so to say. They would have accomplished the same, or actually something better, with less resources.

Instead they fork and fork to specialize each fork on something, instead of a well made main project that can do it all jus as well. With proper coding and routines, there's no reason a project should need to be stripped down and specialized to work better for a single scenario. The idea that code needs to be stripped and specialized to be optimal is a ancient fallacy, generally only believe by people who don't code. It's true only for smaller modules, but never for a project as a whole, unless the project as a whole is badly coded and follows no good practices and routines. This usually only happens with the "I thought myself coding and I'm better than the people who learnt in it school" people.

Link to comment
Share on other sites

Software like Crossover is more about specific configurations and quirks for each software title than forking code per se.

It uses what they call "wine bottles" to isolate the configs for different titles, which is something you could do with Wine as well only that manually without the GUI.

You are arguing that Crossover wouldn't be necessary if Wine had implemented that, but then while Crossover is a commercial product aimed at getting your apps working as good as possible right now with whatever tricks it might need, Wine is about implementing the whole API so eventually quirks aren't needed.

Different focus and different (mid/long term vs. immediate short term) objectives.

It'd be a waste of Wine's dev's resources to go investigating every piece of Windows software and crafting specific scripts to fetch and install this or that DLL from some MS cab file when they can instead keep progressing with the API implementation.

Link to comment
Share on other sites

This topic is now closed to further replies.