It's a common complaint: Open-Source Software (OSS) regret. It starts like a whirlwind romance, full of present and future possibilities. And then somewhere along the way, the luster dulls and the romance is gone, but the OSS remains. Your organization may find itself stuck in a situation where the questions include how it got to this new, undesirable place. In some cases, it may be to ask YOU how to get out of or at least make the situation more “equitable,” AKA more “fair!”

Here are some common complaints that lead to regret:

  • Too many free riders
  • Too few contributors
  • Unanticipated business challenges
  • Can't keep up with the version churn
  • Dependency management
  • Regulatory, security, and compliance
  • Orphaned projects

Whether you host an OSS project or just consume OSS, you'll realize that OSS isn't “free.” There are strings attached, whether formal or informal, whenever you decide to engage in the OSS space. There are always costs, hard and soft. The phrase oft quoted in this context is “free, like beer.” When you're offered a free beer, that's a gift. And the very definition of a gift implies disinterested generosity on the part of the giver. And conversely, there's no future express or implied expectation on the part of the receiver. Notwithstanding, the typical zero-cost price tag associated with code acquisition in the OSS ecosystem, whether it's the relevant license or the intrinsic nature of what OSS is supposed to be, or the project's code of conduct, using OSS mandates certain obligations in one form or another. But because there's a “mandate,” it really ends up being more of a wish and a plea for compliance so that norms, whatever they may be, are relied upon to provide the sharp edges to encourage compliance. In another context, you might refer to this encouragement as public shaming, perhaps via Twitter-hate!

One way to avoid OSS regret is to openly and honestly recognize that A) there are obligations with OSS, and B) you must understand how to fulfill those obligations. Those formal and informal obligations apply to the project and your organization's OSS consumption. If you don't take stock of these things at the outset, any future regrets you may have will need to be addressed with a mirror. Your regrets will be largely composed of hindsight-bias where present facts and circumstances are projected back to past decisions, as if that information were already known. That's the very definition of an unreasonable regret because it attempts to subsequently reframe your OSS value proposition and the entire basis of the OSS bargain, whatever it was at the time. In the past, “free” was acceptable. Now it isn't. And if that isn't bad enough, your technical-debt ledger just increased and, as a result, per double-entry accounting, the other kind of equity, the balance sheet kind, just took a hit. That's not the bargain your organization knowingly signed up for.

The list of complaint's first three items focus on those who decide to create and host a project. The final two are focused on consumers, which, of course, may very well incorporate project hosts as well. The items aren't mutually exclusive to any one category and the list itself, of course, isn't exhaustive. As to these “obligations,” there's no meaningful or pragmatic enforcement mechanism. Theoretically, could one seek redress in the courts? Perhaps, but that isn't pragmatic from a cost, time, or results standpoint.

A good defense to any future regret, one seeing that risks are properly mitigated, is to be a careful decision-maker. Measure twice, cut once. Caveat emptor. Always look at the whole board. Treat things that must be done as bona fide obligations with tangible consequences for non-compliance.

A common new regret, one posted by various project participants, is the frustration with not being able to build a sustainable and profitable business around an OSS project. Some may seek or expect such guidance from the various OSS foundations. In addition to acting as a project governor in the generic sense, I don't see much in the way of meaningful business risk mitigation or business advice. Other projects may decide to go it on their own, independent of a foundation. Does one method have a demonstrable advantage over the other? In my opinion, it all depends on what your motivations are.

That gets me to another point on avoiding OSS regret, which is to take advice from the late Casey Kasem, host of America's Top 40 radio show where he closed every show with “Keep your feet on the ground and keep reaching for the stars.” There's much to unpack in that quote. For this context, it's all about doing the right thing, in the right way, and for the right reasons. In other words, don't get too far over your ski-tips! For your business, that means making analytically and empirically based assessments, not ones born of emotion. One question is whether what you seek to achieve with your business is compatible with your OSS strategy. When the answers are found in the analytics of ROI, are the numbers you're working with accurate? Remember, OSS doesn't have a zero cost!

Here are some poor reasons (without planning) for making your project OSS:

  • We'll get a lot of “cred.”
  • We'll crowdsource innovation.
  • We'll get all the help we need from an OSS foundation.
  • We'll get consulting gigs.

This is just like the previous list, only illustrative rather than exhaustive. On OSS foundations, understand that they're non-profit corporations with an elected board of directors. These foundations typically have specific requirements just to be considered for acceptance. Those requirements are generic and apply to all projects. But what about the specifics of your business and the market you seek to serve and thereby grow your business? A foundation isn't going to help with that for the basic reason that it's your business and that's on you and your team. Not all foundations are alike as to mission, structure, or competence. The gold standards, in my opinion, are the Python and Apache foundations because they're rigorous in adhering to their stated respective intent and they operate like bona fide businesses. Accordingly, if you're going to affiliate with a foundation, choose wisely and, most importantly, stay grounded and keep your expectations realistic.

Let's assume for argument's sake, that some years ago you decided to go head-first, down the OSS trail and today, you want to figure out how to monetize your code. And let's also assume that you didn't hold anything back. It's all out there in the public, for free. As a reminder, it isn't free like beer. But there's no real enforcement authority. Therefore, practically speaking, OSS, in your case, might as well be free like beer! If you take nothing else out of this editorial, take note of that! The good news is that you're not trapped. The bad news is that your choice isn't consequence-free. Of course, if you make these considerations from the start, it's that much less “technical debt” that you'll need to deal with down the road.

One of my favorite phases is “tomorrow is another day.” It's like a blank sheet of paper. Indeed, you can rip the bandage off and re-organize your project for the basic reason that your project owns the copyright for its implementation. Everybody else's rights are subject to a license. The code, at any specific point in time, is what's covered. In covering the code, you may be asking yourself whether you're breaking some sacrosanct OSS rule or norm. Or put another way, are you about to unleash a Twitter hate storm causing your project's past to dictate its future? No foundation or other entity can answer that question. It's a question you'll need to figure out and answer for yourself. If the politics are an effective cudgel causing the status quo to remain for your project, understand that you put yourself in that predicament and that the choice today to remain in that predicament is just as voluntary as the decision to make your project OSS in the first place. And, although there may be regrets, the public complaints are unreasonable because it's a self-inflicted wound. And it's not as though the notion that free can't be sold is new or novel. Even complaining about free riders that take free material to build their for-profit business is unreasonable because, like it or not, that was the bargain you made in the first place.

To avoid OSS regret, if you regard what you're doing as a business, treat it that way. If you want to follow a Gillette-style model where you give away the razor and sell the blades, do that. There's nothing antithetical about that model toward OSS.

Using OSS is a marathon, not a sprint. That early ease often causes project managers to mistakenly think that the way you began can be maintained down the road. That mismatch is related to the expectations you create both for yourself and for those who consume your project.

I started this editorial with the concept of equity, which is about fairness. The most universal concept on fairness is this: A deal is a deal, and that works in all directions. As for the free riders, it isn't free for them either. After all, what's one of the most popular and effective attack vectors besides spearfishing? OSS. Whether as a consumer or a producer, those who decide to wade into the OSS waters need to first understand why they took their shoes off in the first place.

JP