Yesterday and today I attended POSSCON, the Palmetto Open Source Software Conference.Â They’ve got a pretty great speaker lineup this year – Chris Wanstrath, one of the co-founders of GitHub, was particularly inspiring.Â It’s also pretty interesting to me, as a consultant, to see just who shows up for this kind of thing – an open source conference in a town not particularly known for being a giant mecca for open source.Â (In fact, the POSSCON speakers and promoters went out of their way to praise Columbia for opening itself up to the conference – but that’s not the same thing as being someplace like SF or NY, a lodestone that accumulates OSS devs and culture whether it likes it or not.)
So who does show up for an OSS conference in a mid-sized Southern town?Â A pretty randomized mix of “suits”, hobbyists, and developers.
The thing that these three basic types of attendant have in common, of course, is that one way or another, they’re interested in open source software – and for the most part, they’re “for it”.Â But the reasons vary pretty wildly, and they vary in ways that don’t necessarily match up evenly with the three “obvious” divisions that you’re most likely to see at first glance.
So, if you’re “for” open source software, and you’re interested in actively promoting it, it helps to understand not only why you like it yourself, but why others might – and how their perspectives and yours can dovetail, even if they aren’t the same.Â I like to think of these perspectives as “The Three P’s”:
First, let’s talk about philosophy.Â There are a lot of folks – yours truly included – who can get pretty excited about the basic philosophy of open source.Â The idea that we’re all contributing to a permanent increase in the sum of human knowledge and capability is pretty heady, and ultimately, that’s what the OSS philosophy is all about.Â Proprietary software and knowledge can very easily go away and be lost forever (until somebody reinvents it all over again), but OSS is a lot more likely to survive changes in underlying technologies, organizations, and motivations to remain available for whoever might need it.Â Additionally, the reduction of the barrier-to-entry to effectively nil means that a lot of people get empowered further than their monetary income or social circumstances would normally allow.Â When somebody talks disparagingly (or affectionately) about “open source hippies”, this is what they’re talking about!
But maybe you don’t care about that.Â Maybe you’re a hard-headed realist – and that’s where pragmatism comes into play.Â There may be things that you simply can’t do with closed source software, but you’ve found open source software projects that let you do them, or let you do them more easily and cheaply.Â If what you want to do is create a collaborative documentation project, then you probably can’t find anything better than Mediawiki on an open source software stack to do it.Â Or perhaps you’re a developer, and you want easy access to the sheer volume of peer review, in-the-field testing, and free QA and contributions that open sourcing your project can provide.Â Or maybe you’re a small business – or a small cog in a very large business – and it’s easier to get the motivation to put a project together than the approval for budget to pay for software licensing for it.Â Ultimately, though, this P is about a hardheaded, realistic intention to get a job done, and OSS just happens to be the tool that makes it possible for you… or not.Â People who fall into this category are the most likely to have “mixed source” infrastructure, where OSS tools sit side-by-side with closed-source, proprietary tools; whatever gives the best ROI is what gets used, period.
Finally, we have paranoia.Â This one’s a little misleading; the word has negative connotations, but as the old saying goes “you’re not paranoid if they really are out to get you.”Â Someone primarily motivated by the third P is worried not just about the current situation, but about what can happen tomorrow.Â They might be worried about what’s “hidden in the code” in proprietary applications – what if they left a backdoor in the code?Â Can they get at my private data?Â Might they disable functionality and potentially shut down my business because some automated check “thinks I’m a pirate?” – or they might be worried about the changing motivations and viability of other organizations – anybody who started creating documents in the 80s has probably been through at least one horrified realization “I still have the data from that old app, but I don’t have anything that will open it!”Â Corporate mergers can also create some pretty nasty situations for the end-user; big orgs frequently swallow small orgs with the express purpose of getting access to the smaller org’s customer base… and putting them in a “forced switch” situation where the app the end-user originally installed is no longer available or supported, so now the end-user has to migrate to something that may cost more money, may not have the desired feature set, or may for whatever reason “just not fit”.
Conversely, all three P’s can be viewed the other way: someone might think “it’s my work, I don’t want to give it away!” or “things are only as good as what you pay for them” or “how can I control it if I don’t have to budget for it?” and be philosophically in opposition.Â They might believe that the documentation isn’t sufficient, or that the support structure isn’t rigid enough, etc. and be pragmatically opposed.Â Or, they might cling fiercely to the idea “it’s not safe if there isn’t somebody I can sue” or “I don’t want the whole world to know intimate details of how my systems work!” and be opposed on grounds of paranoia.
It’s important to think about these “three P’s”, and how they apply to you, to others around you, and to each other.Â If you’re advocating OSS and want to see it more widely used in your community, understand your own motivations for it, and understand the motivations of the folks who you’d like to spread it to.Â If you’re curious about OSS and trying to figure out how or why you should use it (or care), understand your own motivations, and go from there.Â And if you, or someone you’re discussing OSS with, are primarily motivated by only one or another of the three P’s, be sure to address how the other two P’s inform the one that’s the primary concern, rather than wasting your time flogging philosophy to a pragmatist, or pragmatism to a paranoiac.
3 thoughts on “Perspectives on Open Source: The Three P’s”
The third P is particularly funny since there are allegations that OpenBSD has an FBI backdoor that was added ten years ago.
It would have to be one hell of a subtle backdoor to survive ten years of OpenBSD auditing. Theo deRaadt is … intensely focused on security.
Yup… looks like my immediate “I smell a rat” reaction was most likely correct.
I don’t think people outside the biz really, truly stop to think how difficult it would be to sneak a backdoor into a really active, high-level open source project – it’s not like you get to just do raw commits without anybody scrutinizing your specific commit first. On big projects like the Linux kernel or network / network security stacks, you generally have a subsystem maintainer looking at your commit first – not just “the whole subsystem after you mess with it”, but your commit, all by itself in patch form against the existing code – and if it’s invasive enough, then it goes up the line to higher-up maintainers and committees. If it does get committed, and if it’s in an active, heavily used project, now you’re going to get everything from random interested teenagers to CS professors to professional third-party auditors going over the code, for every reason from random curiosity to academic research to straightforward paid independent auditing for companies who use the project. (Yes, a lot of companies who use open source projects independently pay auditors to go over the code with a fine toothed comb first.)
This is in sharp contrast to closed source software, in which an in-house dev team – whose standards and practices you have no way of knowing – bang away at writing code for an indeterminate amount of time, with an indeterminate amount of internal documentation along the way which you will never get to review, and eventually produce a “black box” product which neither you nor those thousands of teenage geniuses, sober academics, and mercenary professional auditors get to go over.