My travel habits

For the past several years I’ve traveled a lot for work and professional reasons. Being away from home so much can be a drain and is really hard on your body and mind. Over the years I’ve developed some habits that have made my travel life, while not easy, at least less unpleasant. As I complete my final trip for the year it seemed a good time to share some of those habits. The primary goal of all my travel habits is to reduce my stress while on the road. Maybe some of them might do the same for you.

As my friend Chris says, “All travel advice is wrong,” so don’t take what follows as advice so much as a running list of things that work for me. They may not work for you. You may even find some of them silly. That’s OK. You do you, honey. Also note that these are my habits and therefore are not up for debate. You may not agree with them. You may think roller bags are great or that there’s nothing wrong with checking luggage all the time. That’s fine. I encourage you to write a blog post about your habits rather than telling me how mine don’t work for you.

I’ve categorised them into different stages of my travel process:


  • Book the hotel the moment you think you may go somewhere. Nearly every hotel allows for free cancelations within a week to a few days of a reservation. Take advantage of this and book early, even if you don’t yet know for sure whether you’ll be making the trip. Just make sure to set a todo item to verify/cancel the booking in time before you get charged.
  • Book multiple hotels. Is there the chance you’ll be price sensitive at the time of the trip? Book multiple hotels then keep only the cheapest one when the trip rolls around.
  • Use TRIPBAM (or similar). TRIPBAM (yeah, they capitalise it like that) is a service that’ll look for cheaper rates on hotels you have booked. It’ll even re-book for you at a lower rate if you want. Sometimes this can save you a lot of money.
  • Have a single source of truth for travel plans. Having various bits of travel plans scattered across several emails is not helpful. Find a and use a single source of truth where all your plans are stored. Calendar, Tripit, whatever. I don’t care what you use, just make sure it works offline so you can check things when your devices are off the net.
  • Sad to say, but status matters. When you stumble into a hotel at omg-early and your room is already available, you’ll be grateful you focused your stays on a single brand and earned status. When you get that last upgrade on a transcontinental flight, you’ll be glad you concentrated your miles on one airline. It really does make a difference.
  • Sign up for status programs even for a single stay/flight. If you have to book on a brand that isn’t your usual one, sign up for the status program anyway. It can get you insta-perks (like free or faster wifi at hotels). Plus you never know when you’ll need it again and those points can add up over the years (if they don’t expire; many don’t).


  • The answer to “should I pack this?” is always “NO”. Don’t what-if your way to a bag that’s twice as large and heavy as needed. Most people are traveling to civilised places. If you find you actually do need that thing at your destination, just buy it there. (yes, there’s a lot of privilege in that statement, I acknowledge that)
  • There is nothing wrong with rewearing clothes. Five day trip? Pack 2 shirts. That plus the one you wear on the plane will be plenty. Have a spill and ruin a shirt? Towns have shops. Buy a new shirt if you need, or if you’re going to a conference it’s safe to assume you’ll get a t-shirt from that and/or from a vendor on the expo floor.
  • Laundry facilities are a thing. A lot of hotels will have coin-op laundry facilities somewhere on site. If not, there may be a laundromat nearby. A last resort is using the hotel laundry service, but those usually are really expensive.
  • Always check the weather. Wait until just before you pack, then check the weather. Rain, snow, sun…these things happen suddenly, so it’s not worth it to check too far in advance.
  • Always pack an umbrella. No matter what the weather says, always pack an umbrella. Get one you can always keep in your luggage (and make sure it stays there rather than sneaking off). You will never regret this but often will regret not having it.
  • Travel backpack is far superior to a rollerbag. When I’m navigating a strange city or a crowded airport, I want my hands free and I want maximum mobility. I’ve tried the Tortuga recommended by Wirecutter and didn’t like it. My current long-haul bag is an Osprey Farpoint 55 and I love it for any trip longer than five days. For trips shorter than that I use an Ogio that I received from my friends at
  • Consider 1-bagging it. I strongly dislike checking luggage. It gets lost. It slows me down. Instead, I do everything possible to travel with a single bag that I can put overhead. Yes, I can do this with my Osprey.
  • Pack a separate small bag for onsite. Wait, didn’t I just say to 1-bag it? Yes, but you can pack a bag inside another bag…or your bag can include one already. My Osprey has a daypack that I use during conferences and meetings. I also put all my electronics in it, so if I do have to check the big part of the bag I can keep my gear with me. When I use my Ogio, I slide a BetaBrand Under The Jack Pack in there along with my laptop. Using a minimal bag while out and about means I’m less likely to carry too much and get exhausted.
  • Always pack a small shopping bag. A friend gave me a small cloth bag from a cute used bookstore. It stays in my luggage and has been endlessly useful for holding groceries, souvenirs, and once even as an extra carry on when I accidentally gained too much stuff during my trip.
  • Roll the clothes. Most of my clothes are knit (think t-shirt fabric), so they don’t wrinkle much. I roll them as tightly as possible so each one takes up very little room. Yes, underwear as well. I didn’t think that one would make a big difference but it does.
  • Use packing cubes. I didn’t used to like these, but since I got my Osprey I’m a big fan. I use the smallest Amazon Basics cubes, which have the perfect footprint for the Osprey. Load ’em up, stack ’em up in the bag, zip it up, you’re done. Before this I had things all jumbled up in the Osprey and it got complicated. Now it’s nice and tidy and I can find everything easily.
  • Set out travel clothes while packing. Not only does this let me plan my outfits, it also ensures that the morning of my flight (which inevitably is earlier than I’d like) goes smoothly and quickly. I always regret when I don’t do this.
  • Denormalise some gear. It’s OK to have multiple copies of stuff. For instance, each one of my bags contains a computer power supply so I don’t forget to move it from one bag to another. I also travel with multiple pairs of headphones (wired and bluetooth, each with microphones), because that piece of gear is so important to my mental health while traveling that I can’t risk being without.
  • Consolidate with a multi-plug power supply. I think I’ve purchased about eight of these Anker USB-C/USB-A power supplies (they’re scattered around my house) and I’ll gladly buy eight more. When traveling, with a single plug I can recharge my MacBook, both my iPhones (one for work), my Apple Watch, and my iPad. It’s so good, especially when overseas (more on that in a bit).
  • Retractable cables are great. While I’m a huge fan of using velcro cable ties on every cable and cord I own, when traveling I prefer to use retractable cables as much as possible. I found these multi-plug retractables and they make it a lot easier to find things in my little cable bag. They’re also good in my everyday carry (aka EDC). I can grab one, toss it in a pocket, and take off.
  • Collapsible drinking vessels are great.: I’m not a fan of single-use items, so I try not to use disposable coffee cups or drink bottled water. Instead, I carry (and love) a Stojo collapsible coffee cup and a Hydaway water bottle. These things kick ass and I now can’t imagine traveling without them.
  • Consider a (collapsible!) kettle.If you like tea (and I do) and you travel a lot (and I do), you’re going to be disappointed by most hotel rooms (and I am). Unless you’re in the UK/EU, your room is unlikely to have a kettle. The coffee makers most rooms provide are usually pretty bad. Pack your own coffee/tea and a collapsible kettle and you’re all set.
  • Kitchen towel as a jewelry roll. For years I couldn’t figure out how to travel without tangling necklaces or risking losing earrings. Now I use a simple kitchen towel from IKEA as a jewelry roll and love it. A few basic folds to hold things in place, then roll it up. Everything’s safe and padded and, when in a packing cube, there’s no risk of anything getting lost in transit.
  • A dryer sheet can keep things fresh.Packing a dryer sheet in your luggage not only keeps things nice and fresh in there, it also smells a lot more like home. That can be comforting when you’re going into your umpteenth day on the road. Leave the sheet in your luggage when you’re not using it and things will also be nice and fresh when you get back to that bag for your next trip.
  • It’s OK to have a travel buddy. This one took me a while to figure out. I miss my cats terribly while I’m on the road. To help with that, I’ve started packing a small Toothless. Sure, he’s a dragon and not a cat, but he reminds me of my Nigel, so now he’s my Nigel proxy. It’s nice to have a friendly face of some sort in my hotel room when I return after a long day.


  • Always have buffer time. Due to circumstances beyond my control, I missed my flight on my very first solo plane trip, years and years ago. That was so traumatic that now I’ll very happily get to an airport two more more hours before even a domestic flight. These days I also do it so I can work my airport transit time around my various calls and meetings. I can take those just as easily from the airport, and right up until boarding.
  • Get lounge access. I have both Delta Sky Club Executive (which I buy with miles) and Priority Pass Prestige. Between the two of them, there’s a lounge I can use in nearly every airport I travel to. Contrary to popular belief, most lounges aren’t swanky. They are, however, safe and relatively comfortable places to recharge your devices, take calls, and grab a bite and a coffee. They’re also great because you can leave your stuff at your seat while you go pee without someone calling TSA about “abandoned and suspicious” bags. As someone who almost exclusively travels solo (so there’s no one else to watch my stuff), this is worth its weight in gold.
  • Some airports to avoid… MCO (Orlando) is full of families, each with a pack of kids, and few of whom have ever flown before. It’s hell on earth for a seasoned traveler. CDG (Paris) is crowded, disorganised, ugly, and people aren’t very helpful (in my experience). LAX (Los Angeles) is chaos writ large, especially if you fly Delta since their terminals are currently under construction. I don’t find LAX to be the hellscape others do, but it could be more pleasant.
  • Some airports that rock… PDX (Portland) is my home airport but it would be a joy even without that. SEA (Seattle) is well organised and well appointed. Same for MSP (Minneapolis/St Paul) and SLC (Salt Lake City). Yes, these are Delta hubs and Delta is my airline of choice, but they’re also really nice so I don’t mind connecting through them and having to spend an hour or two in their lounges (which are also usually very nice).


  • Buy/use a local coin purse for local currency and metro cards. I have one that says “Brussels” all over it for my Euros, a Swiss flag one for my Swiss Francs, a Union Jack one for my pounds, one that says “Australia” for my Aussie dollars. When I get home, I just place them in the dresser. When I need to travel to that region again next, there’s no question which one to get. I make sure the coin purse is large enough to hold metro cards then keep those in there as well. The purse also makes life so much easier when I reach my destination, since all the currency stays wrangled rather than in a pile on my hotel dresser at night.
  • Buy international figure 8 cables. I thank my friend Ricardo for this one. The Anker power supply (see above) uses a standard figure 8 plug for the power cord that runs from it to the wall. Rather than carrying a plug adapter (OK, I carry one of those too just in case), just buy the figure 8 cable for the region where you’re going. I have them for EU, UK, AU/NZ, US. This tip alone has saved me so much fuss and clutter and I’m deeply grateful for it.
  • Use T-Mobile. (This one’s for US folks) Not only do I get free wifi for my phone on domestic flights, they also have excellent global roaming plans. They even have a $50 international pass that gets me up to 15GB of data at the same speeds I’d have in the US. I can even tether from it! This has saved my butt more than once when hotel wifi wasn’t enough to handle an online call (Zoom, Skype, or what have you).

On Plane

  • Hoodies are the best. Layers if the plane is too cold. Hood if there’s too much draft or if I want an eye shade. The hood is also great to discourage chatty neighbours. The pockets hold my phone, snacks, batteries, cables rather than lose them in a seat back pocket. I won’t fly without a hoodie.
  • Laptops stow well/quickly/securely behind your back. In a bulkhead seat where there’s no decent pocket in front? Just need to move quickly so the attendant can place the meal down on the table? Close the laptop and slide it between your back and the seat. It’s secure and out of the way.
  • Stay hydrated. This one’s easier because I only sit in aisle seats, of course. Staying hydrated keeps my ankles from swelling up and keeps my energy level from flagging too much. This is a lot easier thanks to my Hydaway bottle (see above).
  • Soften butter under warm entree. That pat of butter that comes with the roll will be a tiny block of ice. The entree is not. I put the butter under the entree while eating the salad and it’s soft by the time I get to the roll.
  • Save crackers/cheese from the meal for later. Many entrees come with a pack of crackers and a piece of cheese. I don’t sleep during flights and on long hauls can get peckish in the middle. I save that cheese/cracker (often in my hoodie pocket) for later to keep me going.
  • Take extra packs of nuts/peanuts for later. Relatedly, if a flight offers packs of nuts I’ll take two or three each time then stash them away for later…where “later” usually means “at the conference, since I’m usually so busy that I miss lunch.”

At the hotel

  • Take pictures of everything. No, I don’t mean in a touristy way (though that’s good, too). When I’m in several hotel rooms over a period of a few weeks, I will mix up room numbers. At each hotel, I snap a pic of the key envelope on my way to your room. Also I take pics of rental car plates, parking spaces, wifi passwords, or anything else that there’s even the slightest chance I might forget.
  • Always keep stuff in the same general areas in every hotel room. Contacts to the left of the sink. Wallets, keys, sunnies by the TV. Charging station on the desk. Not only do I never lose anything, I also have only a small number of places to check so I can pack more efficiently (and without forgetting anything). One of those places is the closet…
  • Hang clothes to air after wearing. If I’m going to wear clothes more than once I need them to air out and not be in a heap on the floor. This also keeps my room tidy, which is nice, but I mostly do it to air things out and to remind myself what I’ve worn already. I also always hang up my hoodie or jacket when I get in so all of the stuff is contained in a single place that needs to be checked when packing. The last time I forgot to do this I had to have a Gore-Tex jacket Fed-Ex’d to me from Boston. Live and learn.
  • Find a local grocer near the hotel. Hotel breakfasts rarely agree with me, plus I’m often working in my room in the evenings. A shopping run to a local grocery store or bodega ensures decent breakfasts as well as snacks and fizzy water for when I’m working.
  • Use melatonin. I’m pretty cautious about sleep aids, but when jet lag is bad enough I’ll slam it down with a couple melatonin tablets. It doesn’t always work for me, but it works often enough to keep trying.
  • Get a red light. Is the bathroom on the left or the right side in this hotel? Where exactly is that table leg, anyway? I don’t want to screw up my sleep more in the middle of the night by turning on lights, so I pack a battery-powered red motion-sensing light. The red light won’t fry my night vision, which is nice. Just before bed I turn it on auto mode and set it on the floor where it’ll be activated when I stand up from bed. This thing has improved my nights much more than expected, especially as I hop from hotel to hotel in a short period of time.
  • Always have comfy clothes for the hotel. Being able to slip into leggings, a baggy hoodie, and goofy handmade slippers really helps my stress level when on the road. This is especially true because I spend so much of my time working in my hotel room. I could easily gain back a lot of luggage space by leaving these out (that baggy hoodie isn’t small), but it’s worth it to me to have “house clothes” while in my room. Those slippers are particularly good for my mental health for some reason.
  • There’s no reason your essentials can’t be fun. I have a foldable comb/brush. It looks like a T-Rex skull. I have a toothbrush with a travel cap over the bristles. It looks like Iron Man and the helmet is the bristle cap. Just because I’m an adult doesn’t mean my stuff can’t still be fun, especially when I’m far from home and need more levity than normal.

So there it is. My big list of my Elaborate Coping Mechanisms for when I’m on the road. Maybe something in there will be helpful for you, but even if not it was fun for me to collect them all in one place like this.

Bon voyage and Vaya con dios.

Don’t just do something, stand there!

Don't just do something, stand there; by Flickr user mc_speedy, license CC BY-NC

Another week, another couple of attacks on the Open Source Definition (OSD):

  1. The first comes from the commercial side, where venture capitalist Salil Deshpande took the stage at Open Core Summit to complain that companies can’t make money from their software if they give it away under an open source license and some other company uses it without paying. He called for changes to the OSD to correct this and claimed that he’s just the VC for the job.
  2. The second comes from the humanitarian side, where Coraline Ada Ehmke has announced the Hippocratic License, declaring it to be open source because, “OSI and FSF are not the real arbiters of what is Open Source and what is Free Software. We are.”

Deshpande’s claim that changes to the OSD are necessary to help companies is laughable, of course. If a company does not want others to use and profit from the code that it made freely and legally available, then there’s an answer to that: It’s called proprietary software licenses, and it slays the mythical dragon that Deshpande is fighting. His OSD fear mongering is great for getting attention and calling his business acumen into question, but that’s the extent of its use.

I am sympathetic to the spirit of Coraline’s new license, which is essentially the MIT but with a new clause limiting use:

“The software may not be used by individuals, corporations, governments, or other groups for systems or activities that actively and knowingly endanger, harm, or otherwise threaten the physical, mental, economic, or general well-being of underprivileged individuals or groups.”

I respect what the license is trying to do and to a large extent I agree with it (and I agree entirely with the sentiment). However, as it clearly violates Clause 6 of the OSD, this is not an open source license and never will be. That said, it seems like a totally fine proprietary license (IANAL) and I, personally, will give a nod of approval to all people who use it as such.

Both Deshpande and Ehmke claim that the Open Source Initiative (OSI) does not get to be the sole arbiter of what is or is not Open Source. Both Deshpande and Ehmke are incorrect. The OSD is a standard definition, used for shared understanding and interoperability. Like other standard definitions, it is maintained by a standards body—in this case the OSI.

It is vitally important that we all have a single shared definition of what it means for software to be “open source.” To do otherwise puts everyone at risk. There are actors in this world who are already trying to pull the existing definition in a direction that lines their own pockets and creates fiscal and legal uncertainty for everyone else. We are already seeing this happen now. How much more of this do you think would happen if people like Deshphande has his way and the corporations each get to define “open source” as suits their purposes? Or if Ehmke’s well-intentioned statement opens the doors to those harmful individuals, corporations, governments, or other groups that she is trying to thwart?

These are just two of the most recent calls for changes to the OSD. In the past year there have been many more. In none of these cases have any of the ones calling for change brought their proposal before OSI. They are not working through the official standards body that maintains and guards the definition of “open source.”

But, in their defense, it’s not like OSI has told them that. Or provided public instructions for how to make such a proposal. Or said much of anything, in truth. Each time another there’s another attack on the OSD, OSI remains silent. After many such attacks through 2018, in February of 2019 OSI finally published an OSD affirmation statement, signed by many OSI affiliate member organisation. This is the only official OSI statement during these tumultuous times. It is not enough.

OSI, I call on you to make a statement. Let people know that you hear their concerns, even if you do not agree with them. Give them a better alternative than simply shouting their discontent from stages and blogs. Provide a way for people to propose OSD changes for open consideration and discussion. Perhaps even host a summit or symposium where people can openly discuss their concerns.

Just 👏 do 👏 something.

Disclosure: I was the author of the OSD Affirmation Statement during my tenure as a Director on the Board of the OSI.

The problem with Amazon and Open Source isn’t Amazon

Wrong Way
‘Wrong Way’ by Elaine with Grey Cats on Flickr; CC-BY

Recently a friend wrote asking me “what’s up with Amazon and open source?” and “is there a chance these new licenses will be approved by OSI?” What follows is my reply.

There’s been a rash of open source project relicensing happening the past few months, and in nearly every case the company making the licensing change is claiming that that they’re doing it to protect the project in question from Amazon.

That is a big steaming pile of bullshit.

First of all: There is absolutely nothing wrong with how Amazon is using these open source projects. They are operating completely and entirely within the bounds of the licenses of the projects. Fingers need to be wagged here, but not at Amazon.

These projects are not being relicensed to protect them from Amazon. Claiming that they are is at best naive and at worst wilfully lying. These companies are relicensing projects to cover for the fact that they are ignorant of how to run a successful business. They knowingly released their secret sauce under permissive licenses and have discovered that doing so means that competitors can create more compelling product offerings based upon the same technology. This is entirely in accordance not only with the licenses that these companies knowingly chose, but also with a competitive market. The only problem with this is that it came as a surprise to these “open source” companies and now they’re reacting poorly.

If these companies actually cared about the projects, they would have invested the resources to build stronger communities around them. They would have reached out to Amazon, encouraged them to contribute back to the projects, and helped them to do so. They would NOT have taken the few community contributions—and you will find that most of these projects do not have many contributions from outside of the originating company, showing how poorly they managed their communities—they would not have taken these contributions from community members and then locked them behind proprietary licenses, violating the trust of their community.

You will find that none of the companies that have relicensed their projects address any of these issues. They don’t discuss how they tried to engage Amazon in their communities, how their attempts fell on deaf ears or were rebuffed. They can’t do this because thus far there is no evidence to show they even tried. I know a lot of the open source leadership at Amazon. They’re good people who care deeply about free and open source and who are working to do the right thing by all of the communities of the projects they build upon. They would have been very open to hearing how they could make a positive difference in those communities. They’re a relatively few people across a very large company, so it may have taken a bit more time to get those contribution balls rolling, but they would have worked very hard to do so…had they been approached.

So don’t fall into the trap of unquestionably believing the recent spate of anti-Amazon propaganda. It comes from, without exception, companies that simply do not appear to understand how to operate successful businesses. From what I can tell, they’ve received poor advice from their VCs. Not knowing any better, they understandably followed this advice and now they’re paying the price.

As far as whether there’s any chance these new licenses will be OSI approved, I answer a pretty definitive “no.” There are two reasons for this. First of all, these companies would have to submit the licenses for review. OSI does not just go looking for licenses to review. License creators must take the action to say, “Hey, this is a new license that we believe adheres to the Open Source Definition. It’s valuable to us and to the community that it be recognised as such. Could you please review it and confirm that?” So far only one company has tried that and they failed to get their license approved, because of the second reason…

In order to become OSI-approved, licenses must adhere to the Open Source Definition (OSD). These new licenses do not. While the ways they diverge from the OSD are varied, the most common ones are that they violate either “6. No Discrimination Against Fields of Endeavor”, “8. License Must Not Be Specific to a Product”, “9. License Must Not Restrict Other Software”, or “10. License Must Be Technology-Neutral”.

#6 is the one most violated by these licenses. Restricting to non-commercial usage is fundamentally against the spirit of free and open source software. From the very beginning, Stallman himself was very emphatic that people be allowed to make money from free software. He and FOSS leaders after him realised that preventing people from making money from free and open source software will doom the movement. It is vitally important to FOSS that people be encouraged to use it in commercial and for-profit ventures. This will help foster the spread of FOSS. These licenses disregard both that and the benefit of this clause of the OSD to the whole of FOSS in preference to their own singular commercial needs.

In fact, the vibrant cloud-based and cloud-native environment within which most software companies operate now and which makes so much innovation possible (including that of these misled companies), exists because companies have released their technologies under OSI-approved licenses and have come together to collaborate on common and powerful tools. This is the culture that successful companies embrace. Even Microsoft, the former nemesis of free and open source, recognizes that this type of collaboration is critical to the continued growth and evolution of the company.

To be perfectly clear: There is nothing wrong with making money from software, FOSS or otherwise. Choosing to use a proprietary license for software is a valid business decision and one I support. Choosing to use an OSI-approved license is an equally valid business decision and, again, one I support. However the license to choose for the software created by your company is just that: a BUSINESS decision.

There are many potential variables to consider and those variables will be different for each company, but “how will we make enough money from this to maintain and grow the company sustainably?” is one that is consistent across all of these decisions. If a company’s answer to that is, “we’ll just give away the software to bring in leads” but they don’t have a compelling enough commercial offering on top of that to convert those leads to sales, while their competitor converts those leads and more using the same technology, that is NOT the fault of open source software, licensing, or culture. That’s a company that doesn’t understand how to do business, and blaming Amazon isn’t going to change that.

Farewell freelancing, Hello Juniper Networks!

Hello, World. Please say hello to the new Director of Open Source Strategy at Juniper Networks.

For the past few years I’ve freelanced as an open source strategy consultant, helping various companies understand, use, release, and contribute to free and open source software in ways that are as effective for the company as for the community. As of today, I’ll still be doing that, but solely for Juniper.

As you can imagine, the choice to give up freelancing for a Real Job™ was not a simple one. After speaking with the folks at Juniper though, while the decision wasn’t simple it was definitely easy. Juniper gets it. They understand how critical free and open source software is to their business and to the world, but almost as importantly they recognise that doing this right will take time and dedicated attention, to the community as much as to the technology.

I know everyone who makes an announcement like this says, “I’m excited!” so the statement has nearly lost its meaning and become a platitude, but…well, I’m honestly excited! I’m looking forward to working with Randy Bias, Megan Sugiyama, Bikash Koley, and the rest of the Juniper team, across the entire stack.

We’re going to release and contribute to a ton of excellent software, and join and support a lot of communities. It’s going to be great.

Commons Clause is a Legal Minefield and a Very Bad Idea

Image from page 256 of Bugle-echoes : a collection of the poetry of the civil war, northern and southern (1890)

I recently received a question from Christine Cardoza, journalist at SD Times:

I am writing a story on all the controversy in the industry going on with the Common Clause license. I know it is not an OSI approved license, but I was wondering if you had a statement you could provide on this. Some of the sources I have talked to say they do believe this still promotes open source and that the OSI needs to change some of its rules, so I would really love to include OSI’s take on this if possible.

Her article will be out soon, but she gave me permission to publish my response now:

Hi, Christine. I believe there were plans for OSI to make an official statement on this kerfuffle, but I don’t know where that is in the process. What follows is my professional opinion as an open source strategy and policy consultant for businesses and should not be construed as an official OSI statement.

First of all, terminology: Commons Clause is not a license. It’s a clause that can be applied to licenses. Specifically, it’s intended to be applied to OSI-approved licenses. By restricting people from making money from a project where it is applied, the Commons Clause directly violates Item 6 in the Open Source Definition. As the Open Source Definition is no longer applicable to those projects, they—quite literally by definition—are no longer open source. At best they can be called “source available.”

The Commons Clause FAQ states that “[t]he Commons Clause was intended, in practice, to have virtually no effect other than force a negotiation with those who take predatory commercial advantage of open source development,” however at no point have I seen a statement from either the Commons Clause creators nor any project(s) applying it that they attempted other approaches to encourage collaboration from those they see to be taking “predatory commercial advantage” of their projects. For instance, Redis recently applied the Clause to a few of their modules due to “…today’s cloud providers…taking advantage of successful open source projects and repackaging them into competitive, proprietary service offerings.” Their statement on the change does not say, “We approached the cloud providers and asked them to collaborate, but they refused,” or even “We approached the cloud providers and asked why they do not collaborate and how we can improve this experience for them.” From the outside looking in, it does not appear as though Redis tried to encourage collaboration before throwing a tantrum and relicensing to this proprietary license. That’s not how to be a good free and open source citizen.

As far as that is concerned, their stated reason (“taking advantage of open source projects”) does not square with their actions, as instead of relicensing the project (Redis) that is being taken advantage of it relicensed a few modules instead. While this could be seen as them testing the waters prior to a large relicensing of the main project, the core developer has stated that this will never happen. Therefore it does not seem as though the relicensing will gain Redis much beyond some major damage to their reputation. It feels as though they—an open core company—looked at that open core, decided it was a little too large and they could be a stronger business by shrinking it by a few modules. That’s a completely valid business decision which I would not fault, but it’s not the stated reason for the relicensing. The entire situation is quite perplexing.

And then there’s the Commons Clause itself. Heather Meeker helped to write it. She’s no fool and is a very accomplished and well-respected intellectual property lawyer who has a career of experience working with free and open source licenses. Despite this skilled help, the Commons Clause team came up with a restriction against selling that is so broadly stated that it puts an impressive number of people at risk of license violation should they come into professional contact with any project that is under a license tainted by the Commons Clause:

“…practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software…”

According to this restriction, I as a freelancer would violate the license if I helped a client who used Redis and happened to use one of these modules with the tainted proprietary license. I would probably be held liable even if I were unaware of the use of those modules. I’m far from the only freelancer who looked on the Commons Clause with horror. For instance, Jim Salter, a freelance system administrator, network specialist, and author, says he now feels he can’t work on any project that involves Redis lest he put himself at risk. He’s only one of many freelancers I’ve heard express these thoughts and state outright that they will not work on projects involving Redis. They simply can’t afford to lose their livelihoods due to a legally vague license.

As to the question that open source needs to change, I’ll simply direct you to my blog post on the subject and summarise it as: Open source does not need to change; people simply need to learn how to do business. Stop using open source and expecting it to do the hard work of creating a successful business. It’s a tool, and it’s a great one, but it’s only a tool.

Open source is NOT a business model (and your business will fail if you think that it is)

Southern Pacific Sunset Limited Diner, Budd Company, from SMU Collections, Flickr

Consider this conversation:

Person 1: Did you know that 60% of restaurants close within three years of opening?

Person 2: Oh no! We should change the fundamental definition of “food”. That will fix it.

How does that sound to you? Ridiculous? Good, because it is. Now compare this conversation:

Person 1: Did you know that a lot of “open source” companies can’t make money?

Person 2: Oh no! We should change the fundamental definition of “open source”. That will fix it.

This conversation is just as ridiculous, yet I’ve seen many versions of it recently. Some misguided souls are saying that the Open Source Definition must be changed to include matters of revenue and profit (AKA “how to make money from open source”), because open source is a business model. Let’s just get this settled once and for all, OK?


According to Harvard Business Review, it’s difficult to define ‘business model’. Some of the definitions they’ve collected over the years are:

  • “All it really meant was how you planned to make money.”
  • “…assumptions about what a company gets paid for…”
  • “…a good business model answers…How do we make money in this business?”

There is a great number of potential business models, but “open source” is not one of them. It is, instead, one of the many tools that can be employed in order to make a selected business model work as expected. The most common form of employment here for open source is in open core, which is itself just a variation on the freemium model. In this model, the open source is the tool that is used to entice potential customers to come to the company and hopefully to hand over their money for additional features or advanced support.

Going back to the restaurant example above, saying that open source is a business model is like saying “food is a business model.” Both are things that can attract potential customers, but each is just one of the tools that get customers there. Usability, suitability (market fit), advertising, good service, open source… Each of these is among the many elements that can help convert a prospect into a customer, and each is employed differently depending upon the market and business model.

Therefore open source has not, does not, and should not concern itself with business any more than food concerns itself with business. If there is a business that has a business model that is not living up to expectations, and if that business model uses open source as one if its tools, it’s illogical to blame open source for the failure. That business is asking the tool to do all of the work, rather than learning how to use the tool effectively.

The best way to have a successful business is not to rely on trendy business models and buzzwords. It’s to learn and practice business administration, to learn what the customer needs and values, and then to find a business model that will deliver that value while also supporting the profitability of the enterprise. For some companies, that business model may be open core, but it’s worth researching the past performance of open core companies before taking that plunge.

In 2015 John Mark Walker published a series of articles on under the title, How to Make Money from Open Source Platforms. In the first article of the series, he makes the astute observation that no successful product has come from an open core company. The rest of the series investigates other business models that companies can explore related to open source products and projects. He shows how it’s possible to make money and build a successful business around free and open source software, but that success is due to savvy business acumen and not necessarily due to the free and open source software itself.

So, please, take more care when selecting a business model for your company, and please stop thinking that open source itself is anything more than a tool to help execute that business model.

Redis Labs and the Questionable Business Decision

Redis Enterprise is Everywhere
A screenshot from the Redis Labs website, taken 2018-08-21.

I’ve been trying to take a bit of a break from writing, but considering what I do for a living, how I spend my free time, and the baffling level of WTAF of today’s news, taking a break from break-taking seemed in order.

Today Redis Labs announced that it was adding something called the Commons Clause “…to certain components of open source Redis.” It acknowledges that this means those components are no longer open source, but hand waves that away and implies that it’s not a big deal.

It’s a big deal, and it’s a bad idea.

The Commons Clause is intended as an add-on to OSI-approved licenses. Its primary purpose is to remove “the right to Sell the Software.” Unfortunately, it goes on to define selling as:

…practicing any or all of the rights granted to you under the License to provide to third parties, for a fee or other consideration (including without limitation fees for hosting or consulting/ support services related to the Software), a product or service whose value derives, entirely or substantially, from the functionality of the Software.

Which, you know, is monumentally vague and won’t at all cause problems in court, now will it? Yes, it will. Despite that, the Redis Labs legal and executive teams decided to go forward with this relicensing. What did they hope to accomplish?

Did they hope to force Amazon and other big corporations to stop eating the Redis Labs lunch? If so, they’re going to fail. What will happen is that Amazon, probably in conjunction with Google, will fork Redis to avoid this problem. While it could continue using and developing this fork internally, it’s more likely that they’ll release the fork as a FOSS project, thereby wooing away the existing Redis community and contributors. This will allow them to continue operating as they already are without having to bear the entire burden of maintaining the newly forked project. Redis Labs, on the other hand, will be left with the entire burden of maintaining the original Redis project.

But maybe the problem was that Redis Labs was already carrying this entire burden. Their statement does, after all, include this line that implies this may be the case:

Redis Labs is leading and financing the development of open source Redis and deserves to enjoy the fruits of these efforts.

A review of the Redis project contributions (which I have not done) would reveal whether this is what’s happened. If it is, then there are better ways to play nicely in the free/open source playground than to take your ball and go home when someone does something you don’t like. For instance, you could evaluate why there are so few other contributors to the project and then take action to improve those numbers. Or you could approach the biggest users directly and ask them why they aren’t collaborating more, then cooperate with them to help encourage contributions. Or, if you’re relicensing everything anyway, you could switch to something like the AGPL, which would cause other enterprises either to release their own source code or stop using Redis. Of course, this would probably just lead to a fork as mentioned above, but at least Redis Labs would come out looking like a shrewd member of the FOSS community rather than a foot-stamping child.

The entire situation is just perplexing. This sort of change undoubtedly had to receive approval from a lot of very smart people at Redis Labs, and that approval undoubtedly happened after many hours of discussions and emails. Despite that, they decided to go forward with this unfavourable change. If I were one of the investors in Redis Labs, I’d be raising a skeptical eyebrow and taking a good hard look at just what in the heck is going on over there. Questionable decisions like this shouldn’t be able to get through so many layers of leadership without being shot down.

Anyway, you can look forward to a bevy of thinkpieces from free and open source software luminaries in the next few days, all doing the same sort of finger wagging and WTFing that I am. None of us think this is a good idea, which is to be expected from our ilk and is not really news. What interests me now is seeing how the rest of the market reacts. What will AWS, Google Cloud, and the others do with this news? And how will this affect the revenues and profits of Redis Labs? Will they be able to keep up their streak of 10 quarters so far of double-digit growth?

Let’s find out.

Open Hardware: Good for Your Brand, Good for Your Bottom Line

Article originally published in the June 2018 issue of Linux Journal

I don’t know how to put this, but Hardware is kind of a Big Deal, and thanks to the Internet of Things (aka IoT), it’s getting bigger every year. The analyst firm IDC expects spending on IoT to reach nearly $800 billion USD by the end of 2018. A study by Intel shows that by 2025 the global worth of IoT technology might be as high as over $6 trillion USD, whereas Forbes reports that the global market could be nearly $9 trillion USD in 2020.

These statistics are based on the traditional model of closed design and development of the chips, boards, and objects that will make these devices a reality. However, what if hardware developers were to learn from and leverage the popularity of free and open source software (aka FOSS)? What if the future of IoT were Open? It’s my belief that the device developers who apply the lessons of FOSS to hardware development will be those best positioned to become the powerhouses of that $9 trillion market. Similarly to software, open hardware will be seen first as a differentiator (rather than an eccentricity) and later, as the industry matures, as the default operating mode for hardware development.

Open hardware will require a lot of evolution before it becomes the default development paradigm for IoT. The current state of open hardware closely resembles that of free software thirty years ago: it exists, but in a nebulous form. While organisations such as the Open Source Hardware Association and the Open Hardware Repository are working to change this, the fact remains that there currently are few clear legal, social, or procedural norms around open hardware development. There is no hardware equivalent of the Open Source Initiative‘s list of approved licenses, or agreement on whether a license is even needed at all. The diversity of tools required for hardware design makes collaboration and interoperability more difficult. These legal and procedural questions contribute to a very high barrier to entry for releasing designs as open hardware. That barrier isn’t insurmountable, however. Already advancements in 3D printing as well as emulation and virtualisation through digital twins are enabling types of collaboration that were impossible just a few short years ago. As these methods continue to adapt, the resulting emergent and open processes and norms will drive further and faster innovations.

The openness of hardware will also be hampered for a while by the limitations imposed by chip makers. For instance, the n Mark I voice assistant speaker is certified as open hardware, but includes components built upon proprietary chipsets and boards. Joshua Montgomery, CEO of Mycroft, sees this as a valuable stepping stone toward an entirely open hardware platform. “For now, a lot of open hardware is like LEGO™: while the bricks themselves aren’t open, the designs built with them can be.” This stepping stone has enabled Mycroft to iterate on the Mark I, which incorporates off-the-shelf hardware like Raspberry Pi and Arduino, to create the Mark II, which features a board custom- and openly-designed for security, privacy, and flexibility.

Chip makers are starting to catch on to the advantages of open, however. SiFive has released an entirely open RISC-V development board. Its campaign on the Crowd Supply crowd funding website very quickly raised over $140000 USD. The board itself is hailed as a game-changer in the world of hardware. Developments like these will ensure that it won’t be long before the hardware equivalent of those LEGO™ bricks will soon be as open as the designs built using them.

In the March 2018 issue of Linux Journal I encouraged companies to wait until they’re secure and established in their market before releasing mission-critical software as open source. The reason here is, of course, that it’s quite simple for someone else to take that software, spin up a new cloud instance, and create a company that competes in your market. There are very good business reasons for a company retaining its software intellectual property until the company has locked in its market.

However, that’s not currently the case for hardware. The complexities involved with manufacturing are far more daunting than those around launching a new software firm. The knowledge, regulations, testing, and tooling involved with bringing new hardware to market create a massive—and massively protective—barrier that’s compounded by those undefined legal, social, and procedural norms I mentioned earlier. This provides open hardware startups the freedom to share their designs after (or even before) product launch while still retaining prime mover advantage, simply because no other company would be able to spin up the tooling required quickly enough to impact the sales and market of that prime mover. Once a piece of open hardware is released to customers, the company creating it is already so far ahead of any others that would use its designs that there is little danger of market loss or competition. According to Josh Lifton, CEO of Crowd Supply, even after helping hundreds of creators launch their open hardware products on the platform, “…we have never gotten any report of an idea from a Crowd Supply project getting stolen.”

While open hardware does not share free and open source software’s business risks for releasing of intellectual property, it does share its difficulties in attracting contributors and building a community. While both open endeavours represent the field of dreams for creators, it remains true that if you build it, they will not necessarily come. This is especially true for open hardware where people are not only less used to the idea of contributing, they’re also often less prepared to do so. Aside from the specialised tooling required to read, manipulate, and understand hardware design files, there’s the additional problem of a knowledge gap. Relatively speaking, far more people are equipped with the knowledge and resources necessary to contribute to FOSS projects. When source files are distributed for a free and open source software project, many people already know what to do with them. When source files are distributed for an open hardware project, comparatively few people will have the electrical engineering, industrial design, stress analysis, or other related experience (let alone the very expensive tools required) to contribute effectively. While this naturally leads to considerably fewer contributions to and collaborators on an open hardware project, it also means that those collaborators are more likely to be qualified and their contributions of a higher quality.

Hope of contributions should not be the primary reason for releasing hardware designs under an open license. As Kaia Dekker, CEO of Keyboardio points out, building a business while relying on volunteers for contributions “really isn’t something that necessarily works out.” This is a consideration that’s overlooked by a lot of the new breed of “open first” software businesses springing up these days, but that the sparse contributions make impossible to ignore for open hardware.

Despite this, open hardware still allows companies to reduce the time and expense required for research and development. For instance, Dekker says, developing the Keyboardio Model 01 would not have been practical without the open platform of Arduino or the vibrant community around it. Open hardware components are similar to libraries or modules for software: they allow an organisation to add functionality without having to develop it themselves. Entirely new products, such as the Keyboardio Model 01 or the Mycroft Mark I can come to market thanks to what are essentially off-the-shelf open hardware components.

Joshua Montgomery of Mycroft AI points out that as important as the R&D benefits were to their company when they were getting started, they’re finding that opening the new design of the Mark II is also opening possibilities that they’d not have seen had they kept their hardware proprietary. Through careful design of the Mark II board, Mycroft has created a new off-the-shelf component that partners and other businesses can use, in combination with the open source Mycroft Artificial Intelligence platform, to add a voice assistant feature to their own devices. This increases adoption of the AI platform software along with the contributions and collaborators on it.

By designing their hardware to work in many different contexts then releasing it as an open solution, Mycroft also has gained the benefit of economy of scale for themselves as well as for all companies using the open component. When all companies order the component from the same manufacturer, the subsequent “run” of the part becomes cheaper for every company that uses it. This open supply chain also reduces risk for all participants. Should a supplier fail or withdraw from manufacturing a component, with open hardware it’s possible to spin up tooling in another location. With proprietary hardware, it’s possible if not likely that companies reliant upon that component will need to redesign their products when a component is no longer available. Naturally this type of economy of scale will depend a lot upon the market and company strategy, but the Mycroft example, even in these early days of open hardware, proves that the open approach can provide innovation opportunities and benefits to innumerable companies and entrepreneurs.

According to Kaia Dekker, none of these benefits would be possible without the communities that form around open hardware projects. “It opens doors to us that would be closed otherwise.” Keyboardio has found unexpected success in recruiting firmware development and other talent from their community. That same community can develop after-market accessories for the Model 01, adding, if they wish, features such as wireless capability thanks to the open hardware at the core of the device. This ecosystem of accessories as well as the supportive community has strengthened the Keyboardio brand as their community members have become their most passionate and outspoken advocates. Keyboardio has found that the transparency has increased their perceived reliability in the eyes of their target market, which itself increases the market’s trust in them. Josh Lifton agrees and says that many Crowd Supply creators have seen similar results. “A lot of these people are early adopters and innovators. This type of person usually has a strong community-minded ideology.”

The transparency of open hardware does more than build trust in its communities. It also builds trust in the entire customer base. According to Joshua Montgomery of Mycroft, the “radical transparency” of the Mark I and Mark II devices help to support their reputation for privacy and security. Increasingly, this sort of reputation can have a huge impact on companies looking to enter certain markets. Open hardware ensures that there is never a black box. Consumers, regulators, and security auditors all have equal access to the designs of the devices. In an environment where customers are more privacy aware than ever, this type of transparency can be a powerful differentiator for products.

In 1997 Clayton Christensen detailed the dangers of ignoring the new paradigms in business in The Innovator’s Dilemma. Hardware and IoT creators today are at risk of stumbling straight into that dilemma if they don’t embrace the type of innovation and collaboration that free and open source software has proved is possible. While the ecosystem and contribution norms are still taking shape around open hardware, it’s clear from the benefits listed above that the current environment provides enormous opportunities for companies willing and able to work with and mold that ecosystem. The companies that recognise this now are those that will lead the way for several decades to come.

The Past, Present, and Future of Open Source

Last week Christina Cardoza of SD Times published an excellent article about the first 20 years of open source. I was interviewed for the article, but naturally only part of the interview was used (there were other excellent folks to speak with as well).

Here’s the complete text of that interview.

What really marked the start of open source software in your opinion?

What really marked the start of open source software was the start of Free Software. Without the genius insight of Richard Stallman (aka RMS) that existing copyright and licensing mechanisms could be leveraged to enable the distribution and sharing of software—freely and openly—none of us would be here talking about this today. There would have been no open source software history without the work of GNU, FSF, GNOME, and others. All of software development owes them a huge debt.

Any “start” demarcation beyond that assumes that open source software is an entirely different thing from free software, and that’s just not true. While there may be exceptions, generally speaking all free software is also open source, according to the open source definition. Beyond that there’s a spectrum starting at the stalwart reciprocity of the GPL and the Four Freedoms and running through to the neutral permissiveness of MIT licensed software.

Each end of this spectrum—and every point on it—is a philosophy, and each has existed since people started thinking about the nature of software. Therefore I don’t think there’s any way you can point at a single moment in the history of software and say, “There. That spark right there. That’s open source being born.” It’s not really possible. The release of Netscape or of Java may have captured mindshare and imaginations, but they’re lagging indicators of the birth of open source, not leading ones.

What did the open source landscape look like 20 years ago, and how have you seen it evolve?

Twenty years ago is right around when I was starting my tech career, so while I was aware of, used, and advocated for free and open source software I was more focused on finding my place in tech and paying off student loans than on contributing and becoming a part of the community. I didn’t become really dialed into the FOSS landscape for another three or four years, and wasn’t able to travel and explore that landscape widely for several years after that.So with that in mind…

I like to think of free and open source software as evolving through epochs or versions, much like any software would. FOSS v1.0 was the the dawn of Free Software thanks to RMS and the thousands of others who helped to bring Free Software into the world. This version is usually considered more “wild west” and programmer-driven. Programmers building tools for programmers, driven by a philosophical belief that Sharing Is Good And Right.

The launching of the Open Source Definition and the creation of the Open Source Initiative also brought with them the beginning of FOSS v2.0. In this version FOSS gained mindshare and acceptance, becoming normalised.

What we’re witnessing now is the beginning of FOSS v3.0. Free and open source have evolved from niche and mission-driven movements into Business As Usual. Version 3.0 is rocketing in—propelled by an explosion of corporate involvement, contribution, and sponsorship—but at this speed there’s a very real risk of losing sight of the mission and the bigger picture of FOSS. How are we in the free and open source software communities going to work with the corporations to teach them the human and business benefits of that bigger picture, and how are we going to help them continue to be involved, to contribute, and to sponsor FOSS, but also and importantly to understand and respect that mission? It’s a critical question and one not enough people are discussing.

What do you think was the tipping point for enterprises to realize the importance of open source software?

To be honest, most of them still haven’t realised the importance of free and open source software. I’ve seen companies shut down their open source programs. I’ve seen companies swear they don’t use any open source software and then seen the stunned looks on their faces when they’re shown how much of their stack is free and open source software. I’ve seen companies release fauxpen source, either by throwing unlicensed and unsupported projects over the wall and calling them “open source” or by releasing them under proprietary licenses and claiming they’re “open source” when at best they may be “source available.”

While, yes, there is that explosion of corporate involvement, contribution, and sponsorship, it’s fueled by a tiny fraction of companies. We’ve come a long way, and it’s been wonderful to be along for the ride, but it’s unfair to say that we’ve already crossed the tipping point as there’s still so much work yet to do. That’s our task as we develop and evolve FOSS v3.0.

What is the state of open source software today, and what areas still need to be improved?

For all the decades of their existence, the predominant development approach of most of free and open source software has been “by programmers for programmers.” That’s gotten us this far, and that’s great. However, we’re not going to move FOSS much further if we don’t shift from that approach to one of “by programmers for others.” The usability, accessibility, and documentation of most FOSS projects are in such a state as to be entirely out of reach of people who don’t spend their lives steeped in technology and software development. We’re not going to further the missions of free and open source software if we can’t start developing software that reaches out to a new market of users and, most importantly, meets them where they are rather than expecting them to read code, edit config files, or open up a terminal just to perform basic tasks. If FOSS can’t expand beyond the server and the enterprise then it will never realise the dreams that brought it to life in the first place.

Answers (c) VM Brasseur; Licensed CC BY-SA

Questions (c) Christina Cardoza

FOSS as a Part of a Corporate Sustainability Plan

Article originally published in the May 2018 issue of Linux Journal

Free and open source software is a critical part of your company’s supply chain. Here’s why and how you can include it in your corporate sustainability plan.

In 1983 the United Nations convened a commission of 22 people to investigate the question of the worldwide environmental and social impact of human development. Four years later, in 1987, the commission released Our Common Future, more commonly known as the Brundtland Report in honour of Gro Harlem Brundtland, chairperson of the commission. This report detailed the very real socio-environmental issues facing humanity. One of its recommendations was for governments, organisations, and companies to start engaging in what it called sustainable development. That is, “…development that meets the needs of the present without compromising the ability of future generations to meet their own needs.”

Since then there’s been steep growth in the number of corporations that maintain and operate according to a corporate sustainability plan. These plans encompass environmental as well as social aspects of doing business. They encompass actions within an organisation—such as natural resource usage, diversity and inclusion, and fair treatment of employees—as well as those external to the organisation—such as the sustainability operations of their entire supply chain as well as the overall impact the corporation has on the Earth and its inhabitants.

The benefits of sustainability

A sustainability plan impacts every facet of an organisation’s operations and can take a fair bit of effort to implement and maintain. If that’s the case, then why are more corporations putting these plans into action every year? While it would be nice to think that this occurs for entirely altruistic reasons—taking care of the Earth and its inhabitants is simply the right thing to do, after all—the fact of the matter is that studies repeatedly show that properly implemented corporate sustainability plans are very good for the bottom line.

Innovations and profitability

Sustainability requires partnering and collaborating not only across groups within the organisation, but also with many external to it. These collaborations expose a corporation to new ideas and innovations in market, process, policy, and product, all of which can lead to improved profitability while moving the company toward its sustainabiity goals. Without the support and engagement of all employees, a sustainability plan will fail. Therefore the execution of a sustainability strategy requires a shift in management from the old style of command and control toward a modern style of trust, communication, and employee development. By empowering and training employees, a sustainable corporation improves its ability to execute plans while also increasing employee satisfaction and retention. Beyond just innovations, profitability is increased through reduced expenditures, entry into new markets, and a lower cost of capital.


Investments are also impacted, as more investors are now looking at a corporation’s sustainability plan as a deciding factor on where to place their money. When you think about it, it’s surprising that sustainability hasn’t been a primary investor consideration before now. The strategies that support a successful corporate sustainability plan, focusing on what’s good for society and the environment, are also those that do good for the company. Protecting the organisation’s value and supply chains enables it to ensure it will be around for a good, long while. That longevity—and plan to maintain it—is very appealing to investors in search of both stability and a positive return on their investments. Despite this, studies show that most high level corporate managers still don’t recognise the importance sustainability holds for investors. This provides a great opportunity for those managers who can launch and make a corporate sustainability plan successful before their competitors.

So, yes, corporate sustainability planning (when done properly) is that proverbial rising tide that floats all boats. However, for companies that rely upon technology to keep their business operating (read: all of them), there’s a major component that’s usually left out of their sustainability plan: the software.

Open source software is a part of your supply chain

Operating systems, databases, libraries, infrastructure management and orchestration… No matter what component, all software is a part of your company’s supply chain. How much do you know about it? Do you know what your company’s software supply chain looks like? How much of that chain is or depends upon free and open source software? If you haven’t investigated this before, you’ll likely be surprised by the answer. If you look at little deeper, you’ll be even more surprised to discover just how few people maintain and support the software on which your company relies to operate and do business.

However you look at it, this arrangement is fraught with sustainability concerns. Socially, allowing so few people to perform so much work for so little compensation is inappropriate and does not scale. From a business perspective, it’s very poor practice to rely upon suppliers who may burn out and disappear at any moment. This does nothing good for the longevity prospects for your organisation and dramatically inceases its risk profile.

Open source software is good for sustainability

Don’t get the wrong idea: I’m not here to spread Fear, Uncertainty, and Doubt (aka FUD) about having free and open source software projects as a part of your supply chain. Even a quick glance will show that you’re unlikely to receive as much value and flexibility from proprietary solutions (if they even exist). Proprietary software is incredibly expensive, less flexible, leads to vendor lock-in, and is at least as likely to disappear without notice. 90% of software startups fail, taking their products and their code with them. The high cost, low innovation, and equal risk of mortality for proprietary software makes it a less appealing solution when considering the longevity and sustainability of your own company. Free and open source solutions are simply the better option.

What is YOUR software supply chain?

The answer, then, is not to cut out the free and open source links in your supply chain. No, the actual answer is to include free and open source software in your corporate sustainability plan. Unlike proprietary software, free and open source (FOSS) solutions enable your company to take action to ensure that the FOSS projects themselves are sustainable. So, how can your company do that?

For starters, if you haven’t done so yet, take this opportunity to become very familiar with your company’s software supply chain. Certain links in that chain will be more important and more strategic than others. While your software sustainability efforts should include all of the links in the chain—FOSS or proprietary—you may find that it makes sense to focus more of your investment in these strategic links.

Build a culture of contribution

As you’re evaluating and integrating your software supply chain into your corporate sustainabilty plan, start communicating internally about the importance of this supply chain. This communication should be across the entire organisation, not simply constrained to the technical departments. By communicating and including the entire company, you open up more avenues for ideas and innovations in sustainability as well as start to build a culture of sharing and contribution that will aid in all your sustainability efforts, FOSS or otherwise.

That culture of contribution will be critical for the next step: empowering staff members to contribute back to the FOSS projects on which your company relies. Reporting bugs and requesting features is one way to contribute, but fixing bugs, adding features, and contributing those changes upstream to the main project is what will lead to improved project longevity. It often can make sense for a company to pay team members to work full time maintaining and enhancing strategic free and open source software projects, but even small contributions submitted by individuals scattered across the organisation can aggregate into a large amount of work toward sustaining projects on which your company relies. Making it easy for team members to contribute will make it much more likely that they will support the projects through their contributions. Remember, too, that FOSS projects need more than just programmers in order to thrive. Enabling contributions from your QA, design, marketing, and other departments will enhance the entire ecosystem of the free and open source software that enables your company to operate, adding to its longevity and reducing risk both for it and for your own company.

Share the load

As you review your software supply chain, consider the problem that each one of those links in the chain is there to solve. Your company is not the only one to have those problems. These are issues faced by many organisations, and no one company will be able to solve these shared problems.

Therefore the next step in integrating free and open source software into your corporate sustainability planning is to release the software your company has developed to solve problems shared by others. Of course this doesn’t mean you should necessarily release the software that provides legitimate market differentiation and value for your company, but there are undoubtedly several tools developed internally that are not of strategic market value but that solve specific problems. By releasing these tools, you enable collaboration with organisations that share similar problems.

By working together to solve these problems through free and open source software, all collaborators share the load of development. This allows them to benefit from the tool while also freeing up internal resources to focus on strategic value creation for their markets. In a case study created by Open Tech Strategies and released by the World Bank, collaboration on free and open source software tools led to a 200% return on investment for the collaborators. Sharing the burden of maintaining these tools ensures their longevity and stability while reducing institutional risk. The end result is a more sustainable business and a healtier free and open source software ecosystem.

Join a Foundation

Depending upon the free and open source software in your supply chain, one approach toward sustainability may be participating in the organisations and foundations formed to support projects that are strategic to your company. By joining organisations like Open Source Initiative, Eclipse Foundation, Apache Software Foundation, and the Linux Foundation, your organisation not only has a seat at the table when discussing the future of strategic FOSS projects, it also gets the opportunity to meet, discuss, and collaborate with companies it may not have had occasion to interact with otherwise. By bringing together disparate organisations and providing not only a shared purpose but also a safe environment for collaboration, these foundations enable member companies to learn from each other and to open the doors for new partnerships and innovations.

Think strategically

I’ve said it already in this article but it’s worth repeating that, just as with the rest of your corporate sustainability plan, it’s crucial that your company’s approach to supporting free and open source software projects be strategic. While it’s tempting to contribute to all FOSS projects equally—and certainly the projects themselves would not complain—from a sustainability point of view your organisation should try to focus its resources on those projects that make a material difference to your company. Material difference means that a project, were it to stop being developed or maintained, would severely impact the operations of your company. These are the FOSS projects most directly linked to your organisation’s longevity, and also makes them risk factors for your corporate sustainability plan.

In order to determine which projects are material to your corporation, you must be fully aware of your software supply chain. This involves not only looking at the free and open source software that allows your company to operate, but also digging deeper to learn on what projects those projects rely. It’s all well and good to acknowledge that the authentication library used for your product is material to company longevity, but if that library itself relies upon cryptographic functionality in another—woefully under-funded—project, your company may be exposed to unforeseen but preventable risks. Ignorance of your software supply chain is no defense against vulnerabilities. Cultivating an awareness of the entire ecosystem within which strategic and material FOSS projects operate will help secure corporate longevity and sustainability.

Make a business case

Focusing software sustainability efforts on material and strategic concerns makes it considerably easier to incorporate free and open source software into the business case for your company’s corporate sustainability plan. It may be tempting to skip this step, but if you do so studies show that it’s likely your sustainability plan will fail. When you pause to consider this, it makes perfect sense. Why should a corporation invest so many resources in shifting the way it does business, up to and including its very business model, if there is nothing in it for them? Again, setting aside altruistic appeals and the fact that taking care of the Earth and its inhabitants is just the right thing to do, being able to make a well-researched and detailed case that doing so is good for the bottom line makes it more likely that even the less environmentally- and socially-minded leaders in your company will get on board with the plan. Don’t simply list what changes will be necessary to enact a corporate sustainability plan, but also reveal exactly what is in it for the company for making this effort.

You’re all in this together

As mentioned earlier, it’s important for any corporate sustainability plan to create a culture of contribution across the entire organisation. If upper management does not communicate what the plan is meant to accomplish and why, it will fail to get the support of the employees who actually have to do the heavy lifting of implementing that plan. Without the support of the entire organisation, your corporate sustainability plan will fail. Sustainability must be a 360 degree effort, not simply something dictated from on high. All members and stakeholders of the company must understand what the sustainability plan is, what impact it will have, what part they specifically will play, and how they will make a difference to the overall outcome.

This communication is hard enough when the plan is simply about environmental and social concerns, issues with which most people are familiar, but it becomes much more difficult when unfamiliar concepts like “free software” and “open source” enter the mix. This is why it’s so important to begin the discussion as early as possible. It can take some time for people to understand that “contribute back to free and open source software projects” can be as meaningful and impactful to the corporate sustainability plan as “reduce water usage,” “use energy from renewable sources,” or “eliminate the gender/race pay gap.”

To help with this communication, rather than dictating implementation details to middle management, company leaders should instead set software sustainability goals for each team or department and then allow each group to define how it can best contribute toward those goals. For technical departments their contributions may be as straightforward as providing patches or releasing internal tools, while less technical departments may come up with less obvious approaches to helping the effort. By empowering each team to approach the problem in its own way, the company is not only encouraging innovation but it’s also building trust within its ranks. This trust, as mentioned before, increases the effectiveness not only of the sustainability plan but also of other operations undertaken by these teams. This trust also leads to higher employee satisfaction and retention. The overall culture of the company evolves into one that is more collaborative, innovative, and therefore sustainable.

Keep yourself accountable

A vital part of any corporate sustainability plan is the company holding itself accountable for delivering on its promises to itself, to its stakeholders, and to the communities on which it relies. Fostering a culture of collaboration includes supporting open communication. That openness must permeate all levels of the company. Embracing and supporting free and open source software and their underlying values can help to cultivate the communication required for accountability. Instituting inner sourcing is a good way to encourage collaboration, communication, and cross-functional accountability on your corporate sustainability plan.

Accountability can also be included at an organisational level by way of performance reviews. For this to work, each employee must understand how they contribute to the overall corporate sustainability plan so that they can work toward meeting their particular goals. This is especially important at the executive level. When leaders are held accountable for their sustainability strategies and plans, it reinforces the importance of the effort to the organisation and encourages participation by all members. Reporting on the company’s progress on its sustainability plan also provides accountability to external stakeholders like investors, partners, and customers. For many companies, it can be uncomfortable at first to embrace this form of open communication both internally and externally, but if they are able to make this shift they’ll reap the benefits of sustainability. It can be a difficult journey, but it’s one entirely worth taking.