Close

Lifecycle of Code in Common

A challenge with all commons arrangements is the care required to maintain the shared resources to avoid tragedy of one type or another. In the case of digital "Free Software" and open source software, while there are important needs in caring for good software. These are sometimes not well understood by the developers and even less well understood by the users.

The analogies to common land only partially apply because of the digital nature of software. Software is now distributed over the Internet which is a hybrid public/private, shared, world wide infrastructure. A copy of a software work makes it more widely available with no impact on the original. If copies are used widely and code improvements are given back to the maintainer/distributor of the software everyone benefits from improved software and there is no degradation. Physical goods like land degrade when shared but software benefits when shared. One of the best examples of an information common is wikipedia.org.

A challenge is that enlightened self interest over a short time period does not illuminate the entire ecosystem of software. This can result in small decisions and free riders that endanger the sustainability of the shared common. Stewardship and collective trusteeship can only be appreciated when viewing the system over a longer period of time. What do you think? Please comment below.

We hope you join us for our meetings in Berkeley at Bobby G’s Pizzeria. We meet on the second and fourth Sundays of each month.

Open Washing

I sense a trend. Cloud people and others now love "open" so it seems that open concepts are more popular right now than proprietary, closed source concepts. I think practice is still catching up with hyperbole. This has been called open washing. Tim O’Reilly has been warning for years about creating data silos using open software for services. It’s not just about code any more.

There are also troubling disagreements like the tangential renaming of the wikipedia article about open source software by non open source grammarians that insist on a hyphen when it is not used this way in industry despite it’s more proper grammatical approach.

If people can’t even agree on the terms then erosion occurs from the more pure ideals of free software and open source software when describing them to others. It dilutes the effectiveness of proponents of these ideas so that we must explain complicated history to describe these anomolies along with educating people about the conepts.

Even the most dedicated, well run and financially stable proponents of open data and open source find open source solutions lacking for their own desktop use in their operations. Some of them are either unable or unwilling to take the (necessarily significant) time and expense to address their own needs with open solutions because it is seen as tangential to their primary mission. Any IT department that prefers open solutions finds that, whether they like it or not, they are forced to support some users and their proprietary software tools because there are gaps not addressed or not as effective in getting their real world work done. If open tools are not as effective then other solutions must be used. Who can fault them for making rational decisions?

Yet if nobody addresses these edge cases everyone loses. Until someone chooses to scratch their own itch for their own good then everyone who tries to follow in their footsteps will face similar tough choices. What have been your experiences with this?

We hope you join us for our meeting in Berkeley at Bobby G’s Pizzeria. We meet on the second and fourth Sundays of each month.