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.
If you would like to see your thoughts or experiences with technology published, please consider writing an article for OSNews.
- "Page 1/2"
- "Page 2/2"