Forking: A Social Event

Github Explorer by Franck Cuny

The key driver of innovation in open software development is forking. If a community or individual software developers would like to continue the development of a given code on their own for any reason, they can create a new fork. The developers simply take a copy of the source code, which open software development permits without violating copyright, and continue to work on it on their own to create a distinct project that from here on competes with the original. Later on, no more code will be exchanged between the projects.


Forking is a social event as well. It invariably creates a split in the developer community and there is social pressure against taking such a drastic step that splits the community’s development resources. Software developer and author David Wheeler has compared a fork to a “vote of no confidence” in parliament. He also suggests that most forks die on their own due to the substantial efforts needed to maintain and develop them.


Modern technological tools such as Github have smoothed out the drama surrounding forks to a certain extent as these allow to copy code from a software repository with the aim of merging it back into the original trunk once improvements are made, a more constructive approach than a complete break-away.


One of the key forks in the recent development of the popular use of the internet was when Matt Mullenweg and Mike Little in 2003 created a fork to b2/cafelog, a tool for bloggers to design, organize and publish their content. The result was Wordpress, which today is considered to be the most popular open source blogging and content management tool in the world.


Had Wordpress been developed by a few developers not committed to open source development, this would hardly have been possible. The tool has instead been developed by its community. There are over 1,600 design themes developed and made available by designers to any user of Wordpress, both for free and at a fee. As of December 2012, there were more than 22,000 plugins available, little add-on tools that vastly expand the basic Wordpress install and allow for customization.


Flat hierarchies are key to the innovation prowess of start-ups, as they ensure the motivation of their employees who can spend their entire day jointly developing products and delivering them to their customers. But maybe flat hierarchies might not be possible without today’s technology that allows employees to constantly chat with each other, whether they’re in the office or at home, whether they are based in San Francisco or else where.




Github repositories can be accessed from just anywhere. After-work drinks aside, the company’s entire internal communication takes place in Campfire, a chat tool for businesses that effectively serves as an online project collaboration tool. It enables entire teams to share files and software code, no matter where the individual team members are working from.

Startups in software development therefore do not need physical locations any longer. Their employees could just work from home or any where in the world.


"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."


This is, however, a direct contradiction to the prerequisites of agile software development outlined above. This approach puts a lot of emphasis on pair programming and face-to-face meetings. Daily scrum meetings are obsolete if the team’s members are shattered around the world. The sixth principle of the agile manifesto, published in 2001 by some developers to define their new approach, says: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”.


Instant messaging and the online sharing of code has allowed for global collaboration on projects as well as the entire outsourcing of development
departments to lower-cost countries such as India, but this major trend in software development again contradicts the principles of the innovation approach of agile software development.


Martin Fowler, one of the founder of agile methods, has sad that in his experiences at his company ThoughtWorks, that has outsourced parts of the company’s software development to Bangalore, India, the continuous implementation of code helps to overcome some of the disadvantages of separated locations and timezones.


"A late night bad build is much more serious when the remote office is running off the same build."


The company uses its CruiseControl tool to allow all its software developers to work on the same code base, preventing that teams go astray due to the different dynamics in and between centres. CruiseControl allows developers to instantly see what changes have been made by teams in other locations. Just like in agile development, if changes to the code are constantly integrated into the main code or the product itself, mistakes made are likely to be smaller and quicker to be found.


“It’s generally accepted practice that if you commit changes to the mainline, you should not go home until you have received the email message from CruiseControl that says that your changes resulted in a successful build. A late night bad build is much more serious when the remote office is running off the same build,” Fowler wrote on this website.


In order not to lose the advantages of face-toface communication entirely, ThoughtWorks constantly has what it calls an ambassador of its US team posted to the site in India and vice versa. This role is performed by a new employee every few months to ensure a fresh package of office gossip finds its way to the other location and to ensure both sites are in the loop on developments at the other teams. The company is trying to make heavy use of internal wikis to reduce the need for scrum meetings, which are difficult to observe across time-zones.


Concluding, Fowler says the costs and benefits of offshore development are still open to debate. There are other voices that break away more fundamentally from the traditional workflow at large corporations and thereby also from the face-to-face principle of software development.


Github’s Zach Holman is passionate about the asymmetric form of communication in chatrooms and email. He argues that when sending an email to a colleague or posting something to a team’s chatroom, co-workers can decide when they would like to respond without being distracted from what they are doing and thereby disturbing their creativity. This is what meetings do: they are symmetric in that they force every participant to structure his working schedule around them, distracting him from his actual work of developing products and interacting with clients.


In practice, most employees at startups actually come to a physical location. Ryan Tomayko, also of Github, has also noted two important functions that offices still hold: physical meetings are still needed to discuss matters of broad vision and strategy that can not be scattered into small pieces of postings to web boards. Office also ensure informal social interactions in the form of after-work drinks and gossiping over lunch.


>> Ch. 8 Conclusion