开源软件里也有不少路线斗争, 可供参照: Flame Wars, Forks and Freedom


所有跟贴·加跟贴·新语丝读书论坛

送交者: BLT 于 2008-11-22, 07:01:52:

http://www.osnews.com/print/9501/Flame_Wars_Forks_and_Freedom


Flame Wars, Forks and Freedom
posted by Vinayak Hegde on Mon 24th Jan 2005 19:44


In the news media, it is generally shown that flame wars and forks are detrimental to the growth of FOSS (Free/Open Source Software) But if we see the history of FOSS, both flame wars and forks have played a crucial role in determining both growth and direction of important projects. There are also arguments that this leads to fragmentation and marginalization. There is some truth in these arguments but there are a lot of benefits which are often overlooked. This article looks at some of the benefits of forking and flame wars through history.

"Page 1/2"
Why forks happen ?? - A peek at history

There are several reasons why a fork may occur - Here are some examples:

* A particular group of members is not happy with the further technical direction of the project. An example of this is the recent fork of FreeBSD 4.x code base, by some members of the FreeBSD core team resulting in the formation of the DragonflyBSD project. FreeBSD 4.x had scalability problems and could not make optimum use of multi-processor machines. With multi-processor machines becoming cheap and common in the enterprise space, this problem had to be solved quickly. One of the objectives of the FreeBSD 5.x release was to solve this problem. The programmers who are working on Dragonfly BSD were not happy with the way this technical problem was solved and forked the project forming DragonflyBSD. DragonflyBSD is now focused on providing Single System Image (SSI) Clustering. It also aim to solve the scalability problems of the 4.x BSD series while being robust and flexible enough to run on uniprocessor machines as well as massively clustered machines.
*

Patches are not getting accepted and changes are not being done fast enough. The users/developers are unhappy with the pace of development. This happened some time back with the GCC team. Cygnus (now a part of RedHat) had based it's business around supporting the GNU Compiler collections and had several engineers working on it. The list of patches pending and waiting for the review was getting bigger and bigger by the day. Finally patience ran out and Cygnus forked the GCC project (creating EGCS - Experimental GNU Compiler System), keeping the forked branch itself GPLed as before. After and EGCS branch became the main GCC branch and hence the fork was "healed".

Xemacs was forked from Emacs as the patches were not getting accepted as fast as some of the developers would have liked. What most people know is that Linux itself almost got forked in 1998 due to the fact that Linus was not accepting patches to his kernel tree as some of the kernel developers would have liked. Fortunately, the differences were sorted out amicably when the threat of a fork was looming large.
*

Another famous fork in recent times was the X.org/XFree86 split. When releasing version 4.4 of the XFree86 Server,the license was changed and most major Linux distributions and BSD variants dumped it for the X.org fork. Before this split could occur, there was another split lead by Keith Packard following several dissatisfaction with XFree86 development. eventually this project was merged with freedesktop.org. Among the problems he cited in the mail was limited development resources, slow release schedules, lack of co-operation with other projects (notably GNOME and KDE) and opacity of the development process. This story was also covered by OSnews .

"Page 2/2"
Benefits of forking

Forks spur competition. It is a bit like evolution. In nature, a new species survives if the differentiation from the dominant group gives it an advantage for survival in a hostile world. That is why the dinosaurs died out and the mammals survived. Being big and powerful is not as important as being able to adapt to changing conditions. Most of the time open source software succeeds, it is because the end users are included in the process of building the software and making decisions. It is inevitable then at some point there will be a divergence of views and a decision has to be made. Sometimes it is not possible to make the right decision as one does not have all the information and/or one's past experiences have led to a certain opinion (which may not be necessarily right according to others). This is fertile ground for a flame war and a fork.

Usually, it is possible that the fork will survive if it solves a pressing need which was overlooked or addressed insufficiently by the core group. Also in open source, after forks if one group is innovating more than the other and taking the right decisions, it will also attract the userbase over a period of time. The source code being freely available means one group can borrow ideas from another. So the best ideas get replicated across the forks. Often it is also seen that a particular developer is part of one or more projects (forks). As many forks want to retain their own identity, there is more innovation for differentiation from the other forks. Innovation is also due to the demands of a specialized userbase (example - cryptographic implementations in OpenBSD and implementation of ssh - OpenSSH). Now this leads to a positive feedback cycle - all the good stuff gets picked up by everyone and everyone is free to experiment more. An example in case are BSD variants - FreeBSD, NetBSD and OpenBSD. FreeBSD and NetBSD use OpenSSH that has been developed by the OpenBSD team. The NetBSD Packages collection pkgsrc has been ported to both FreeBSD and OpenBSD. Forks also bring to notice some pressing need of the community when the lead programmers/core team ignore them. Even Richard Stallman agreed to pursue the egcs fork of gcc as the main branch for further development. Forks can sometimes be "healed" and the codebases merged. The GCC/EGCS example above is a case in point. Forks provide an opportunity for them to serve a specialised purpose while being able to incorporate changes from the new branch.

It is possible that forks may hurt large corporations which like to be able to control the direction of the product. This is the reason Sun will not release Solaris 10 and Java under a OSS license. If at all they release the source it will have some kind on a non-forking clause. Forks are always beneficial to the end user in the long run, though they might cause a bit of pain initially. Imposed control rather than concensus is central to the way big corporations operate but not the way a good team of hackers operate. This is due to the cathedral and bazaar model of development as described by Eric S Raymond.
Flame Wars

More often than not flame wars are precursor to forks - an indication that all is not well within the project. Flame wars can also happen if a radical new design or a drastic change to the project such as a license change or replacing a subsystem with a better one. Flaring opinions and bruised egos can damage the project but also enhance the project by hammering out new ideas in a public discussion (because the discussion is public also means the stakes are high). Bureaucracy and forced conformism is detrimental to the growth of a project. But this is the way order has been established in traditional companies. Flame wars and discussions are central to the development of OSS to explore different design issues, but they also harbor the potential to destroy the camaraderie in a project. It is important that they be taken in the right spirit or the whole project suffers. The reason why flame wars have got a bad reputation are they often get political and personal. But flame wars can also bubble up "thought leaders". If a guy makes a convincing argument and backs it up with working code he will definitely win the confidence of the community.

Linus Torvalds was involved in a famous flame fest with Andrew Tanenbaum over the design of the Linux kernel and also licensing considerations. Tanenbaum brushed aside Linux saying "Linux is obsolete". But Linus held his ground and Linux moved from a toy kernel with few users to an enterprise operating system which companies like Sun, IBM and HP have adopted.


Conclusion

In the short term they have the disadvantage of dividing the teams and sometimes can lead to a lot of duplicated work. Flame wars and forking are not bad but inherent to the way Open source software has been designed. As long as they are done for the valid reasons and not due to political or personal reasons, they will thrive.




所有跟贴:


加跟贴

笔名: 密码: 注册笔名请按这里

标题:

内容: (BBCode使用说明