Slashdot Mirror
XFree86 Core Team Disbands
mumumu was among the many to write with this news: "XFree86's release engineer David Dawes has announced that "a majority of the XFree86 core team has voted in favour of my proposal to disband the core team". XFree86's News Headline has a short message about it. Why, all of a sudden?
What is the successor of the XFree86? Xouvert? freedesktop.org?"
Why would a successor for XFree86 be needed? As I understand it, this is only a change in the "political" structure of the project, not its end.
Programming can be fun again. Film at 11.
Sounds more like the "core" team weren't actually doing the development anymore, and that they felt it was unfair to be the "core" team when they weren't doing the work.
Nothing to see here folks, keep moving.
read.
the.
exceedingly.
short.
article.
cyn, free software and *nix operating systems enthusiast.
Face it.
"Core Team" Development models are out-dated and sound more M$'ish than Open Source'ish.
While several projects continue to use the "Core Team" model, like FreeBSD, in my opinion, the politics involved ain't worth it.
For XFree86, it's time for change. Hopefully, in years to come, we will see a more efficient graphics subsystem for Unix (MacOS X may be an example) weather it be by a XFree86, XF86 Fork, or some other system (NOT framebuffer because fb doesn't work well with some hardware)
I think it's related to the "firing" of Keith Packard from the core group, when he was one of the few people trying to move X11 into the 20th century.
The abundance of abandond projects on Sourceforge would appear to disagree with you. Open Source projects are usually NOT the domain of hundreds and thousands of globally diverse developers but rather a very small and very active "core" team. Once that core team leaves (and I'm not talking about XFree86 here) then the project usually dies. Why? Because even though the code is in the public domain there is a lack of willingness to get involved or a lack of skill of those who ARE willing or a lack of time for those who are both skillfull AND willing.
Mac OS X and Windows XP working side by side to fight back the night.
False. Enterprise financial apps don't depend on changing hardware every year like graphics applications. And "just plain works" doesn't mean is maintainable. And I would doubt very strongly that someone knows 30-year-old-multi-million-lines-apps of financial code in Fortran well enough to be sure that it does what it is supposed to do...
"I think this line is mostly filler"
Hey, just sharing what I know..Jesus. Go and throw a hissy fit why don't you.
I spent alot of time with the Xouvert crew. From what I understand, Xouvert was formed largely out of this same frustration -- Neither developers nor companies could even get a word in edgewise with them, with means the whole project sits and stagnates... Well, until things like today's event, that is.
The core team dissolving is a good thing, as I see it. It clears the way for XFree to be less Cathedral and more Bazaar.
Bowie J. Poag
Open source development is a Darwinian process. The strong prosper and the weak either die off or adapt themselves to survive in an isolated niche. If a project is so uninteresting or so obscure that it can't attract a new maintainer, then it deserves to die. The carcass remains part of the ecosystem -- scavangers are free to pick the bones for anything useful, or someone can come along and breathe new life into it.
Why is it that the proponents of "one nation under God" are so eager to get rid of "liberty and justice for all"?
The disbanding of the current XFree86 core team does not mean an end to the continuing development of XFree86, it means a change of people recongised as being key players.
The biggest remaining question IMHO is whether there will be a expansion of cvs commit access. I think the former core team realises that new up and coming developers need to be added to the project to subtain the continuing improvement and work with others groups such as X.org, and freedesktop.org. To say nothing of expanding access to video card manufacturers so they can maintain and improve open source drivers for their cards (Most companies are at least partial supportive of 2D drivers, the real issues occur over 3D accelation).
I expect it will end up being a good thing.
I think we should congratulate the core team for doing the right thing. Its pretty rare for any institution to volintarily disband no matter how irrelevant it becomes. I can think of a few institutions a lot less relevant than this group that have continued plugging along for generations.
These people are showing maturity and class usually missing in the software industry. Just by taking this action, the team has refuted one of the more subtle FUD points out there, that projects will eventually peter out or be consumed by internal bickering.
This can be worked around. You move to a new core, and you toss out all the backwards compatibility crap. THEN, you add a backwards compatibility layer or module for the code that still needs it. Surely it would be easier for X than it was for, say, Apple, when they made apps designed for System 6 on an m68k processor successfully run under System 7 on a PowerPC processor. Thus you can get your brand new spiffy clean core with all the latest features while retaining legacy support. You just need to lose the idea that legacy support needs to be maintained at the core...
"Convictions are more dangerous enemies of truth than lies."
I love how people always compare things to Windows, which is the most backwards, un-advanced OS ever.
If you want to compare GUIs, compare with Mac OS X. OpenGL-accelerated drawing? Check. Incredibly rich graphics in apps? Check. No need to wait until 2006. And of course, by definition, right now X is still where it is now.
If Linux always strove to play catch-up with Windows, it would be horrible. Fortunately, it doesn't do that, except in the area of the GUI. It's no surprise, then, that Linux's GUI isn't very good.
Mod down posts with a "Free Mac Mini/iPod" sig, they're spam!
The problem with using C++ because it has resource management is that assumes the resource management model that C++ uses is appropriate for the problem space.
C++ doesn't "have resource management", it has standardized hooks for implementing whatever storage allocation and resource management strategies you want.
You wouldn't use C++ resource management for buffer cache handling in an OS, would you?
Using C++ would give you identical performance to what kernels currently do in C, yet it would greatly reduce the risk of bugs.
In any case, more generally, I see no problem using languages that actually have resource management built in. Some of those are badly designed or inefficient (VisualBasic, Java) and are therefore unsuitable, but others are perfectly fine (Modula-3, C#). Automatic resource management (garbage collection, etc.) is almost always more efficient than anything C programmers do by hand, and it is far less error prone.