Should we open source our software? Can we? What will it mean for our business? Our users? Should educational technology be open source as a rule? These questions, and so many more, continually come up in just about every company and developer community in which I have ever participated or served; and they are all very good questions. Deciding to go open source is a significant milestone in a project’s lifespan, and it should be handled with sobriety and care. Ultimately, it is as much a soul-searching process as a pragmatic one.
Let me start out by clarifying a few things.
To begin with, I am not going to attempt to convince you to adopt open source software in your tech stack. We could endlessly debate both sides of that argument -- a long and arduous journey that would get us just about as far as the other side of the oft-visited townline of Nowheresville (population: the internet).
Besides, I’m fairly certain you already have adopted open source tools whether you intended to do so or not, so let’s not split hairs. I am also not going to blindly state that open software is inherently better, in any way, shape, or form than proprietary software. Nor will I decree that all software, period, should be free and open.
I will note, as well, that when I do refer to free I mean “free, as in speech,” and not “free, as in beer,” but I am not strictly limiting such terminology to the tenets outlined by the Free Software Foundation. However you choose to define “free,” software is expensive to build and maintain. Significant effort, considerable thought, and boundless passion have gone into even the smallest of projects, and that should not be disregarded. All other considerations aside, you can and should ascribe value to your time, and a high value at that. Whether you’re making a business out of your development efforts or it is simply a labor of love, the decision to receive money or not for that effort is yours and yours alone to make, and you won’t receive any judgment here.
With all of that out of the way, how do we then answer those burning questions? Well, first off, it’s time to be honest with ourselves. What is the core value proposition of our offering? We all think everything we do is special and so, by way of the transitive property, everything we do must then represent our core value proposition. If you have truly taken a hard, honest look deep within and have come to that conclusion… I thank you for your incalculable contributions to the world.
For the rest of us, the harsher (more inherently human) reality is that there is some subset of the things we do that truly bring value to the world around us, and that everything else in our offering merely supports our ability and capacity to do those things or -- and there is no shame in this -- do just that one thing.
We could almost begin and end right here. Identify that core value proposition, keep it proprietary, and open source everything else. Let other people use your general purpose tools to make amazing things on their own and, should they end up doing a better job than you at delivering on your core value proposition, thank them for pushing you to up your game, or just be grateful the world will now be a better place because a better solution has been devised and released for consumption.
It is not always that simple, of course. All of the parts and pieces of the code you have crafted may not directly represent your core value proposition, but they may still provide a competitive advantage that should not be dismissed out of hand. So, the next round of introspection should focus on exactly that -- competitive advantages. Business is business (and here I am making the assumption that we are talking about an offering that depends on revenue, from wherever it may come and in whatever form it may take, to survive) and, due to that, there are inherent responsibilities at play -- responsibilities to your company or group and its members, to your users, and to the unobstructed evolution of your offering.
If the “core value proposition” denotes those things that are of unique and meaningful value to your users, then the “core business value” can be thought of as those things that are of unique and meaningful value to you.
The decision of whether or not to open source these components of your offering then becomes a calculated assessment weighing out the pros and cons. Will my core value proposition be made more valuable if I allow outsiders to contribute to my general tools, and do those benefits outweigh the risks of giving up some or all of my competitive advantage? Answer that and you’ll know what you need to do.
Now we are beginning to round out the conversation and truly comprehend the depth and breadth of the decision-making process. In my company, we wrestle with these questions each and every day. We ponder impact and feasibility, considering everything from developer happiness to community stewardship to pure business and so much more. Performing such evaluations is no simple task and requires both humility and candor, and oft times the potential rewards are intangible and amorphous in nature -- but that does not make them irrelevant or immaterial.
Ultimately, the answer to all of these questions is highly specific and individualistic and, for better or worse, there is no magic button to relieve us from having to determine our own course of action. The important thing is that, as a community, we openly and actively engage in such conversations and purposefully choose to not shy away from this level of self-reflection. In so doing, no matter at what conclusion we arrive, if we approached the dilemma with said humility and candor, it will be to the mutual benefit of all.
Is open source the right thing to do? Ideologically speaking, yes. It is difficult to deny the reality that we all derive benefit from the open sharing of knowledge and tools. Perhaps, then, the better question is, “When is open source the right thing to do?”