fork noun repository
A copy of a repository’s master code, allowing one to freely experiment with changes without affecting the original. This also includes a complete departure for the purpose of doing something differently from the original author’s design and sometimes without intent to merge code back into the original master branch.
The question for project managers would be “Is there a natural risk for open source software projects with respect to forking?”
Open source is wonderfully organic in that it grows like a plant. Branches are created overnight, branches may or may not be maintained by others and some simply wither away. Like plants, some software branches are buggier than others. We acknowledge though that our own programs are made up of a collection of the code from these repositories. At the moment of truth when we decide to include some particular bit of code we make a reasonable assumption:
Over time, I assume that this included code won’t change so dramatically that it no longer serves my own purpose or that it will break my own code.
Can we honestly take on that risk for our own venture given the usual number of dependencies in a typical Node.js project, e.g.? Most open source code doesn’t de-evolve quite so destructively usually since it hasn’t reached a level of fame yet. But for some code that enjoys thousands of downloads this necessarily means that many people now are suddenly very interested in the future development of that code. And if this public forum is anything like the inter-department conversations of an average software development company then you may assume that different parties will have differing ideas about what that future should look like. And this then is the risk that we take on: In the future someone else may steer that dependent code in an incompatible direction from our own.
You’d think that each person in the open source arena would have equal say regarding future suggestions and modifications to commonly-used code. I don’t believe that this is the case, to be honest. Big players like Google actively participate in the world of open source. Given their size and the number of developers they can throw at anyone else’s code they could easily steer development efforts into a direction which suits their own needs. In a way, you would think that the world of open source would operate on merit alone. The reality could easily be that open source is very much at the mercy of anyone with the wherewithal to dominate the playing field.
Adobe’s PhoneGap promotes Cordova behind the scenes for multi-platform phone development. Given their level of commitment this will likely mean that over time competing technologies may not succeed. If you choose the wrong technology you could abruptly lose support in the future when some dependent code author decides to hang it up and do something else. Big players like Adobe can enter this space almost overnight and quickly change the playing field for everyone else.
The Fork in the Road
Personally, I use jQuery and jQuery Mobile in my own software. What would happen in the future if somebody there at the jQuery Foundation decided to change up the fundamental ways that the interface works with PhoneGap, the development platform I’m also using? I then find myself as the helpless passenger inside a carriage I’m not piloting suddenly careening down some path I didn’t envision. Not only would my code break for some single build but I might then need to re-evaluate bigger decisions like platform and dependency selections. It might be necessary to even consider throwing labor at jQuery development as an option. If I do choose to depart from the direction they want to go then I necessarily lose support over time as a consequence.
It just strikes me as a long-time software developer that we could use some risk management strategies for what we’re taking on into our projects as these dependencies. Is it then necessary to read outstanding issues on a per-dependency basis and to haunt those discussions? I hope not. I don’t think that the average coder would have that luxury of time on their schedule.