Open Source & Business

This past week I read the “musings” of notable open source speaker Tom Callaway on the intersection of open source software (he uses that term loosely to encompass everything recognized by the OSI and the FSF, and so do I) and business. Mr. Callaway is well-disposed to offer these reflections given his lengthy experience in this very matter at Red Hat. While the astute will notice that the blog entry is from over a year ago at the time of writing - virtually a lifetime in our rapidly changing tech landscape - and would be well complemented by some follow up research, it is nonetheless a succint, informative and blunt piece.

Mr. Callaway quickly and effectively lays out the variety of business models for open source software: from the more well established approaches of subscriptions and open core, to the more newly developing “peace of mind” model of professional intermediaries, and the humorous (perhaps not for the lawyers) model of FUD (fear, uncertainty and doubt) around licensing. But the post is no impartial survey of open source business models: on the contrary, beyond the freely admitted bias toward the Red Hat way, there lies a suggestion - which undoubtedly ruffled some feathers - that the open core model is a “half pregnant” state! He argues, and I find myself in amused agreement, that while it is not surprising that many businesses have taken this route (despite the evident variety of approaches) given the low risks involved, these companies also stand to gain minimal reward. They do not benefit from the sort of symbiotic relationships with consumers that he describes in relation to Red Hat, and in the long term they risk being out-maneuvered by open source alternatives to their proprietary feature offerings.

On the one hand I was happy to note his level-headed footnote that the lack of the market being dominated by open source, particularly the subscription model, is a strong potential argument to the contrary. On the other hand, I can’t help but feel like he exposes what can be a very slippery slope. If open core companies - which at least have a foot in the open source door - risk being left behind by simultaneously depending on proprietary software, then where does the trend stop? Gil Yehuda discussed open source software as a weapon, a means of neutralizing competitors, in his presentation, but once weapons start getting used, it’s hard to stop the “violence”. Does this mean that in the efforts to outflank one another and assume the mantle of the most-open-source-of-them-all mean that we will see a slow death of proprietary software? Admittedly that does sound quite unlikely. Proprietary software is like buying certificates of deposit (at least in more recent years): they won’t net you much in profits, but they’re better than nothing and safer than stocks or gambling. Are they going to go away? Probably not, but mediocrity and obsolesence is a real risk.

Working in Open Source

All of this discussion of open source and business as of late, in addition to my upcoming graduation from Hunter College, raises the question as to how I would feel working at a company that produced open source software. Admittedly, the very first thought that came to me was: oh my, the pressure! Making your code available for public scrutiny is nothing new to anyone with public repositories on platforms such as Github, but this is taking that to another level! Yet this sparked an equal and opposite reaction: we shouldn’t exaggerate and suggest that companies don’t undergo very serious review and improvement at proprietary software companies, but at the least the code is somewhat “sheltered”, at the worst the code can become the result of a pigeon-holed mentality. Think of all of the famous disasters of proprietary software, from major operating systems and lost NASA drones, to buggy video games. This is not to say that an open source way - or an open source community - are wonderful or perfect alternatives, but with proper cultivation they very much can be an approximation of such. Seeing all of the success of Red Hat, Canonical and other companies of the same compatible, I have long been interested in working at such companies, and this course, and all of my recent readings, have only confirmed my impression that yes: I absolutely would work for a company that produces only open sourc software.

Open Source & Democracy

This week I also found myself reading a fascinating article on the (deliberately and cautiously) slow, noble and uphill struggle for open source to come to the aid of election technology and democracy more generally. In particular, the article focuses on the Trust the Vote Project by the Open Source Election Technology (OSET) Institute, and I was very impressed by the disciplined variation of an open source approach they are bringing to the table, namely the “dual-sandbox model” of one environment for fast and innovative development, and the other for carefully reviewed and honed code. While “Linus’ Law” will still hold - and is critically useful here - the approach is a blend between the cathedral and the bazaar methods: the community can help rapidly develop the pieces, but the final product must be carefully assembled.

Of course, this is not just a matter of preference for OSET, but rather the essential process. In our often Luddite world, many are on standby to distrust any technological solution, as if humans are inherently less fallible than their creations. Moreover, the novelty of a major open source effort to develop elections technology means that much will inevitably be made of the success - or hopefully not failure - of this endeavor. No pressure right? This for a project which, fascinatingly enough, must develop software for “an inherently untrustworthy hardware base”. But for all of the inherent challenges, human and technological, I remain hopeful that this serious, measured and inspired meritocratic project is up to the task of ridding us of hopelessly outdated technology, old data standards, and misguided fears.

FOSS Project Log:

Friday, May 1

Friday night I spent a couple of hours rapidly scanning a wide variety of projects, assessing their general caliber, community, issues and room for improvement, in the interest of finding a new project for my group to work on moving forward. I did try to avoid considering projects currently being worked on by other groups in the Open Source Software course (though freeCodeCamp did receive some of my curiosity), and the following is a list of the projects I reviewed:

• OpenCV
• ROS/ROS2
• Ubuntu Yaru Theme
• Vim
• Arduino
• Django
• Matplotlib
• NumPy
• Pandas
• scikit-learn
• Python
• freeCodeCamp
• PythonDS
• TheAlgorithms

I did take a brief look through a few other projects, having found a nice list of open source projects with “Awesome First PR Opportunities” by language, but the above were the major hits. While I was hopeful that in the worst case we could always fall back on projects like PythonDS or TheAlgorithms, which collect samples of data structure or algorithm implementations (and other resources) in one or more languages, this did not truly satisfy and I did end the night still concerned. While not searching for low-hanging fruit, I could not help but be very wary of commitment to a new project after our experience with Atom. In my limited experience, many projects, Atom included, are friendly and relatively active, but once you dig into them you find that issues labeled as “good first issue” or “beginner friendly” are in fact very difficult for an outsider to debug and are really the “easiest” of the remaining bugs, which may not be much for a mature project. Moreover, even where issues do regard genuinely “easier” matters with clear cut solutions, larger projects such as the Python libraries mentioned above, are so picked over that it becomes difficult to determine what remains to be done and stake your contribution claim.

Saturday, May 2

On Saturday, Jessica, Boubacar and I reunited and refused to part ways for a couple of hours until we had settled on a new direction and project. This involved a couple of hours of review and deliberation. In particular we all reviewed potential issues with Pandas, but unfortunately came to naught. I cautiously recommended that OpenCV may ultimately be our salvation for this project. Significantly, this issue and improvement plan - old but still open - are clear statements of intention to improve the state of OpenCV tutorials and documentation, which are certainly in some need of some TLC. Specifically, the tutorials seem to have initially been split into separate language bins for C++, Python and JavaScript, many tutorials are out of date or incomplete, and the quality (grammar, depth of theoretical coverage, code explanation, citations, additional resources, etc.) varies widely. While some serious work has been done to consolidate and improve the tutorials into a single, cohesive and consistent body of tutorials, there remains much to be done.

This did not mean putting aside the possibility of code contributions - and in fact editing or creating tutorials, samples or documentations may yet yield opportunities for doing exactly that - it is reassuring to have meaningful opportunities to contribute to a project without needing to be a domain expert. After some further discussion, we decided to engage in something of a “blitz” review of tutorials, documentation, contributing documents, and issues. Our continuing progress in that regard, as always, can be found here.

Sunday, May 3

Sunday, by necessity, was a somewhat shorter meeting that more or less was a recap of our first impressions, the resources and issues we have discovered and gathered thus far, and planning ahead for development. There were no major revelations: only consensus that there remained plenty of work to be done in tutorials and related code, and that our efforts would be best spent, and well appreciated, by helping in the consolidation and improvement efforts mentioned above. While discussing the contribution and introduction documents, I did notice that two links to NumPy documentation in an OpenCV tutorial were now broken. Boubacar and I quickly launched into trying to find suitable replacements and the conclusion of that brief but fun and hopefully helpful effort is this issue. If nothing else, the issue is a foot toe in the OpenCV pool, testing the waters!

Other Course-Related Activity:

Nothing further at this time.