Open-source software is great, and those devoted to the open-source ethos will tell you why. However, the nature of it can sometimes cause problems when you’re depending on a certain project. Here at Lagoon, which is an open-source project, we naturally use many other open-source projects inside of Lagoon, which means we are relying on other people and communities to help us make sure our product works. The open-source community as a whole generally works pretty well, and large projects that are used by thousands of people are usually updated quickly and often.
But what happens when a bug in a project is breaking something in your project? Or when an out of date project is preventing something from working? How do you manage? Let’s take a look at how we handle this in Lagoon.
Lagoon, as an open source project, consumes a lot of upstream dependencies - be they Golang modules or libraries, npm packages, tool binaries or entire docker images. When assessing one of these packages for inclusion, we need to weigh up how widely it’s used, how well supported it is, and how receptive the maintainers are to external contribution.
So what do we do? We have a few options;
- Wait. We’re not the only people dealing with this issue, and the software will get updated eventually.
- Do the open-source thing and see about fixing it ourselves, and pushing the fix upstream to the source project. Of course this depends on a variety of things - sometimes the issue has already been fixed, but not released, so we can’t do anything about that. If it’s an issue that would take up too much of our engineers’ time, or we don’t know what the fix should be, that’s another problem.
- Fork the existing project, and maintain our changes separately. This is usually only considered because either our use case is too niche for general interest, or if we are stuck using an old version that is no longer maintained by the upstream.
In practice, we do all three - being a good open-source “waiter” is just good manners, but sometimes even when we look to contribute fixes they aren’t accepted upstream, and sometimes we elect to create a fork and then see a change that would resolve our issue come in upstream anyway!
No matter what we choose to do, it’s important to be transparent and keep our users informed - generally by having an issue in our queue, possibly updating documentation as well as release notes.
Sometimes the issues are beyond the scope of what we can fix - for example, a current issue is building Lagoon on M1 Macs. Neither the current version of Keycloak nor Harbor, both of which are critical parts of Lagoon, are supported, and developing Lagoon on an M1 Mac would introduce some differences that would prove really hard to debug, or may require workarounds that aren’t necessary in production. Any fixes to this would require large architectural changes, not just a patch here and there. We’ve made an issue, updated our documentation, and we try to keep everyone in the loop as we wait to see if this is going to continue to be a problem.
How do you handle the ups and downs of open-source? Leave a comment here, or on Twitter, or check out the Lagoon Discord!
Top comments (0)