Don't touch this! Seven types of open source to dance away from

Count the committers for an OSS project, and go from there

Comment In a world where even Microsoft gets the open source religion, the planet’s overall quota for positivity and good karma must be increasing, right? Of course this is not the case, there are bad eggs in every basket and open source has had its share of so-called “openwashing” from time to time.

For the record, it’s not Microsoft and its open stance that comes into question here. Yes, the firm has something of a newfound belief in the value of open source sharing driven by what is still ultimately a commercial goal, but that’s okay.

Microsoft is still a company, a commercial one, like the one you probably work for.

The dishonour here comes about for more delicate reasons. If open source is the “way of things” now, then it’s easy to see why openwashing could become as prevalent as, say, greenwashing, among those firms exhibiting what are merely pseudo-eco credentials.

As a basis qualification, a “green” firm recycling three plastic bottles a week is probably greenwashing. Equally, a firm asking developers to “join” its developer community and share its open source love is probably guilty of some openwashing.

For the record on this point, news agency Thomson Reuters operates this exact practice on its Customer Zone pages. Real openness is open to all, not just to members.

Potemkin villages

As a company involved in numerous open source projects for more than 20 years, it’s safe to say that Red Hat does a fair bit of open source. From its open middleware and enterprise Linux operating system through to its software-defined storage technologies and its more granular level components, Red Hat’s pedigree for openness is comparatively untainted, by most yardsticks at least.

Red Hat CEO Jim Whitehurst used his keynote at the firm’s recent Boston Summit to remind us that operational facades have been around for a very long time.

He cited the false-front Potemkin villages created by Russian military leader Grigory Potemkin along the banks of the Dnieper River to fool Empress Catherine II during her journey to the Crimea in 1787.

Whether the story is apocryphal or not, the phrase has stuck. So where are the Potemkins in open source software development today?

1: Projects without a core focus on meritocracy: Drawn from Whitehurst’s own personal opinions, the number one (okay this list is not necessarily presented in any particular order) reason to question an open source project is one that operates without a central focus on meritocracy. “Modern firms should build a culture that focuses on fostering engagement and debate ... as well as one that defers to a meritocracy over a hierarchy,” writes Whitehurst in his book The Open Organization.

2: Projects with single firm (or single source) committing: This one speaks for itself really. In the past, companies established themselves on the basis of either “economies of scale” or “positional advantage”, but in the future a more open measure of merit will win. Open source projects that are unfairly moderated with any degree of this so-termed positional advantage are not open.

3: Projects with commercial “licensed-only” availability: Licensing being the thorny issue that it is, this point is probably inevitable if still disappointing. Open of course means that an unlicensed version of software must always exist, for free. Locked down versions of open source software with static non-dynamic binaries in fully supported and maintained commercial models are fine, but they should be recognised as something over and above the core source code.

4: Projects with a usability separation factor: Again from Whitehurst’s core “things I don’t like or trust” list comes projects where the open element of the code is so far away (or separate) from the usable elements of software that ultimately it is no longer open source software.

Four is good start, but it is neither a list nor a collection long enough for an obligatory list article (OLA). With this shortfall in mind and in the spirit of total openness, let’s also take in the views of Jeffrey Hammond, vice president & principal analyst serving development professionals at Forrester Research.

5. Projects with consolidated IP or fragmented copyrights: Hammond argues that there is a potential issue in open source software projects that don’t have consolidated IP, and/or suffer from fragmented copyrights.

“Apache and Eclipse require assignment because of this, so that if a patent troll tries to sue, the group can mount a coordinated defence of the project. In practice, I’m not sure this is a huge issue – although Google might beg to differ given its go around with Oracle on APIs and Java in Android," said Hammond.

"In short, it would be a lot harder to defend if there were multiple parties involved,” he added.

6: Projects with dump and run: Not quite as lavatorial as it sounds, dump and run projects are those where we see a vendor contribute a commercial codebase into open source in order to reduce the level of investment they must make to support it. Often this reduction in force happens slowly at first and then picks up speed over time. A potential example here being Apache Flex.

7: Projects with revolving committers: Hammond says he often tells his clients to look for data on how many committers an OSS project has and whether the committer base is stable and makes regular contributions. “When there is frequent turnover it can be an indication of a ‘project in trouble’, or one that’s about to fork. As an example, we could reference NodeJS or even Java under Oracle. In these cases the projects survived the subsequent forks, but that’s not always the case with smaller projects,” said Hammond.

It’s not about the money, money

While this list hardly debunks and discredits any major open source initiatives it does provide some timely (and arguably much needed) additional colour in terms of the way projects may now evolve.

The real existence of openwashing is comparatively minimal and, in theory, the community itself should weed out any bad blood through a process of natural deselection.

That, after all, is the beauty of open source software in its purist sense, namely that it exists because people want to make better software for users, not because they want to build in an open model and then make money from it. Money is nice if it comes later, but it’s okay if it doesn’t. ®

Biting the hand that feeds IT © 1998–2021