Ownership and Inertia in an Open World

A look at some of the issues with open source, particularly the ownership/territorial issue and the inertial issues.

One problem that crops up in open source is ownership. If the user has a bug, and it’s not clear where that bug lives (ie, in the actual application or one of its libraries) it can be difficult to get traction toward a fix. This is true even if the user/bug advocate is somewhat knowledgeable about the environment. The bug advocate goes to the developer community of the application that exhibits the problem, explains the details they uncovered, only to be met with a kind of skepticism or hunch on the part of the developers that it’s Not Our Bug. The bug advocate goes to the developers of the library that may have the problem, and it’s the same thing: downstream is Doing It Wrong. Neither sets of developers really wants to step on the territory of the other set more than they have to. It can get worse. If downstream commits to an idea and tries to convince upstream, only to fail to walk away with a good outcome, they may fork or at least extend the upstream. And the next time, even if it’s a different upstream, they may be faster to fork/extend than to try to engage. And that leads to the other problem of inertia. A hardened outlook by downstream or upstream against third-party interactions can be a sort of inertia. Often times there are perceived allies, enemies (though probably not so harsh, simply seeing them as uncooperative), and neutral (or maybe nearly-abandoned) projects. But there are other inertiæ as well. User inertia can thwart advancements in a project, as can the inertia borne out of developer visions. Often these can be overcome through more liberal forking policies. Liberal forking policies are great and the best way to see projects advance, but they are hard to justify when the projects in question are very monolithic and complex. Forking the Linux kernel, for example, is not something anyone would do lightly. Small software is more liberal about forks, where the amount of code in question, and its complexity, is low. Take Conky configurations and scripts, for example. There are thousands floating around, and it’s relatively simple to take one up and modify it to taste. As none have very widespread adoption, there will be little friction or burden in a fork. But if you want to make fundamental changes to Cairo, so much code depends on it that it’s a major undertaking for changing more than amounts to a few minor patches. Reddit is open-source, but it doesn’t see much third-party adoption because there are few projects that benefit from reuse of its code that aren’t full implementations of its services. If it is possible that some of the code from Reddit can be less-integrated, it would likely see more reuse and therefore more participation by third parties. The bottom line is that while open source does have many benefits, it can have more benefits if we can come to terms with how to best dispose a project to participation and can work out some of the ownership issues that do thwart greater participation.

Please Deposit Two Cents: Cancel reply