Tag Archives: software

Open Source Glossary

When discussing open source with colleagues, I tend to assume that they already know the basics. But, as open source becomes a standard part of all software development, and the number of people working with open source grows, this has become less and less true.

What follows is a minimal viable vocabulary, which I’m posting here so that I can link to it elsewhere when having these conversations, and attempting to assume a lingua franca.

Open Source

Open source refers to software which is developed and released under an OSI (Open Source Initiative) approved license. Open source licenses are those that comply with the Open Source Definition, which sets forth ten tenets which are mandatory components of a compliant license.

Within these tenets, there is a lot of room for variation, and thus there are many licenses that qualify as open source licenses, ranging from extremely permissive (“Do whatever you want with this code.”) to much more restrictive (“You must do these things with the code.”)

While, strictly speaking, “open source” is a legal definition of the license under which software is released, it also implies a project which is run under the guidelines of the Four Opens – Open Source, Open Design, Open Development, and Open Community. In reality, most projects fall short of that ideal in some way, but it is an ideal to be striven for.

Fork

A fork is a copy of an open source project, for the purpose of making changes to the source code. Usually, this is done with the intention of offering those changes back to the original (“upstream”) project for inclusion in future versions (See “PR/MR/Patch”)

A private fork is when this copy is made privately, inside a particular company or organization, without visibility to the upstream.

A public fork, as the name indicates, is done in public where everyone on the project can see what changes are being proposed. This is always preferable, as it allows the project community to comment and participate in these changes, rather than them being a surprise.

A hostile fork is when a project is forked with no intention to ever contribute back, but, rather, to continue to run a competing project indefinitely. This should be considered only in the most extreme of situations.

PR/MR/Patch

A PR (Pull Request), MR (Merge Request) or Patch, are all terms for offering a change back to the originating project (“upstream”), for inclusion in future versions of that project. The terms indicate different ways that the change may be submitted, but all refer to essentially the same thing – a proposed change.

A PR is the desired end-game on any fork. Forks should be short-lived, and have a specific proposed change in mind, rather than being long-running or permanent artifacts.

Upstream

An upstream project refers to the open source project from which you are building. That implies the existence of a downstream – a project, product, or service which inherits some or all of its code from that upstream. For example, Apache Kafka is the upstream for Amazon Managed Streaming for Apache Kafka (MSK). (Which, of course, implies that MSK is the downstream from Apache Kafka.)

The upstream/downstream relationship is symbiotic. That is, a project relies on users, and a product or service relies on the upstream’s health and sustainability. As such, a downstream product or service should do everything in its power to support and sustain the project which it depends on. And project, in their turn, should listen to customers and users, and be responsive to them.

Maintainer

A maintainer is someone empowered to make changes to an open source project, and/or to make releases of that project. Ideally, a healthy project will have multiple maintainers, and there will be healthy discussion and debate around changes that go into a project.

Single-maintainer projects, or single-vendor projects (ie, where all maintainers come from the same vendor/company/organization) pose a risk to the sustainability of that project, since the change in direction from one source can result in the user community being suddenly disenfranchised or surprised. Thus, it is an ideal of open community that there be a diversity of inputs in the pool of maintainers, to ensure that all voices are equally heard when changes are made.

Software Morghulis

In George R R Martin’s books “A Song of Fire and Ice” (which you may know by the name “A Game of Thrones”), the people of Braavos,
have a saying – “Valar Morghulis” – which means “All men must die.” As you follow the story, you quickly realize that this statement is not made in a morbid, or defeatist sense, but reflects on what we must do while alive so that the death, while inevitable, isn’t meaningless. Thus, the traditional response is “Valar Dohaeris” – all men must serve – to give meaning to their life.

So it is with software. All software must die. And this should be viewed as a natural part of the life cycle of software development, not as a blight, or something to be embarrassed about.

Software is about solving problems – whether that problem is calculating launch trajectories, optimizing your financial investments, or entertaining your kids. And problems evolve over time. In the short term, this leads to the evolution of the software solving them. Eventually, however, it may lead to the death of the software. It’s important what you choose to do next.

You win, or you die

One of the often-cited advantages of open source is that anybody can pick up a project and carry it forward, even if the original developers have given up on it. While this is, of course, true, the reality is more complicated.

As we say at the Apache Software Foundation, “Community > Code”. Which is to say, software is more than just lines of source code in a text file. It’s a community of users, and a community of developers. It’s documentation, tutorial videos, and local meetups. It’s conferences, business deals and interpersonal relationships. And it’s real people solving real-world problems, while trying to beat deadlines and get home to their families.

So, yes, you can pick up the source code, and you can make your changes and solve your own problems – scratch your itch, as the saying goes. But a software project, as a whole, cannot necessarily be kept on life support just because someone publishes the code publicly. One must also plan for the support of the ecosystem that grows up around any successful software project.

Eric Raymond just recently released the source code for the 1970s
computer game Colossal Cave Adventure on Github. This is cool, for us greybeard geeks, and also for computer historians. It remains to be seen whether the software actually becomes an active open source project, or if it has merely moved to its final resting place.

The problem that the software solved – people want to be entertained – still exists, but that problem has greatly evolved over the years, as new and different games have emerged, and our expectations of computer games have radically changed. The software itself is still an enjoyable game, and has a huge nostalgia factor for those of us who played it on greenscreens all those years ago. But it doesn’t measure up to the alternatives that are now available.

Software Morghulis. Not because it’s awful, but because its time has
passed.

Winter is coming

The words of the house of Stark in “A Song of Fire and Ice”, are “Winter is coming.” As with “Valar Morghulis,” this is about planning ahead for the inevitable, and not being caught surprised and unprepared.

How we plan for our own death, with insurance, wills, and data backups, isn’t morbid or defeatist. Rather, it is looking out for those that will survive us. We try to ensure continuity of those things which are possible, and closure for those things which are not.

Similarly, Planning ahead for the inevitable death of a project isn’t defeatist. Rather, it shows concern for the community. When a software project winds down, there will often be a number of people who will continue to use it. This may be because they have built a business around it. It may be because it perfectly solves their particular problem. And it may be that they simply can’t afford the time, or cost, of migrating to something else.

How we plan for the death of the project prioritizes the needs of this community, rather than focusing merely on the fact that we, the developers, are no longer interested in working on it, and have moved on to something else.

At Apache, we have established the Attic as a place for software projects to come to rest once the developer community has dwindled. While the project itself may reach a point where they can no longer adequately shepherd the project, the Foundation as a whole still has a responsibility to the users, companies, and customers, who rely on the software itself.

The Apache Attic provides a place for the code, downloadable releases, documentation, and archived mailing lists, for projects that are no longer actively developed.

In some cases, these projects are picked up and rejuvenated by a new community of developers and users. However, this is uncommon, since there’s usually a very good reason that a project has ceased operation. In many cases, it’s because a newer, better solution has been developed for the problem that the project solved. And in many cases, it’s because, with the evolution of technology, the problem is no longer important to a large enough audience.

However, if you do rely on a particular piece of software, you can rely on it always being available there.

The Attic does not provide ongoing bug fixes or make additional releases. Nor does it make any attempt to restart communities. It is
merely there, like your grandmother’s attic, to provide long-term storage. And, occasionally, you’ll find something useful and reusable as you’re looking through what’s in there.

Software Dohaeris

The Apache Software Foundation exists to provide software for the public good. That’s our stated mission. And so we must always be looking out for that public good. One critical aspect of that is ensuring that software projects are able to provide adequate oversight, and continuing support.

One measure of this is that there are always (at least) three members of the Project Management Committee (PMC) who can review commits, approve releases, and ensure timely security fixes. And when that’s no longer the case, we must take action, so that the community depending on the code has clear and correct expectations of what they’re downloading.

In the end, software is a tool to accomplish a task. All software must serve. When it no longer serves, it must die.

GTasks for Android

I use Google Tasks as my primary ToDo list. I switched a month or two ago upon finding out that there’s no decent Teuxdeux app for Android, and now I appreciate it for other reasons.

On Android, I use GTasks, by DATO.

This morning, they pushed an update, which broke certain features, and this resulted in a lot of negative feedback from folks who, like myself, rely on it for daily task management. Within hours, they had pushed a new release which reverted the breakage.

I’m hugely impressed with the app itself, and also with their responsiveness. I’m also delighted with the Google Play Store, which allows for this kind of responsiveness. From what I understand, in the Apple App Store, it would have taken several more days to get the fixed version pushed out, and I would have been unable to use my to-do list until next week, at best.

So, thanks to all the players in this particular scene. If you’re looking for a todo list manager, I can’t recommend anything higher. Oh, and there’s an iOS version, too, but it’s not nearly as nice.

Code Poet

The longer I work in software, the more convinced I am that the term “computer science” is mostly hogwash, as it applies to software development. Writing software is a lot more like writing a story than it is like baking a cake or doing qualitative analysis of soil samples. Given the same task, 3 programmers will do it 5 different ways, and each will have its unique beauty, its unique ugliness, and its unique ways to solve the tricky problems that come up along the way.

I’m lucky enough to work with some folks who have very creative ways to solve problems, rather than cut-and-pasting someone else’s solution.

And it never ceases to amaze me how every industry, no matter how stodgy or boring of itself, provides opportunities for unique creative expression. And no matter how much experience I have, I keep encountering folks with far less experience, but far more creativity and talent. I firmly believe in the old adage that one should hire people smarter than oneself.