Open Source in Industry:

This week the Open Source Software class was graced with a very enlightening, thorough and fun presentation by Kevin Fleming, Head of Open Source Community Engagement at the Chief Technology Officer’s office at Bloomberg. Personally I found myself spellbound, and I am sure that I was not alone in that, following Mr. Fleming cover the wide breadth of Bloomberg’s use of and contributions to open source tools and platforms across many fields: from cloud and distributed computing to machine learning. Perhaps what I found most interesting is the almost casual manner in which this relationship developed. While we learned that Mr. Fleming has his own background in open source software and continues to make contributions in his personal time to this day, the Bloomberg company began using open source software - the most obvious and well-known case being Git - as a practical (and sometimes free!) resource rather than out of some pre-existing dedication to the open source world. As Mr. Fleming pointed out, and I suspect this is the case for countless other companies, this usage and experience - even if only impacting how the company’s product is made at first - serves as great incentive for the company to continue to return the FOSS world, and, in time, to begin paying it forward with their own contributions. A compelling and encouraging component of his talk was just how much of a potent base open source software had been and continues to be for Bloomberg: not parts of pet projects or community outreach programs, but in fact serving as the real muscle below a professional product in which disappointment can be measured in milliseconds and in which the competing impulses of speed and accuracy somehow have to both come out on top.

Should anyone from Bloomberg - or even Mr. Fleming himself - read this blog, I want to convey the following: Mr. Fleming is an amazing ambassador for the company and for the open source community writ large. Not every open source developer may live up to his caliber, but he is an inspiring example of what my classmates and I can strive to be!

Reporting Bugs:

This week I had the pleasure of reading a fun blog post entitled “They Might Never Tell You It’s Broken” from the Pointers Gone Wild blog maintained by Maxime Chevalier-Boisvert. The entry relays the troublesome revelation the author had in the course of developing an open source JavaScript compiler: users of open source software may not notify the creator(s) or maintainer(s) of bugs or issues that they encounter with the software. Personally, I think the author hit the nail on the head with three proposed reasons why a user would not report a bug: a) belief it has been reported elsewhere, b) fear of being embarrassed, and c) lack of interest or investment on the part of the user. The first may only pertain to larger projects where it becomes far more difficult for a user to check if the issue has already been reported, but the latter two are universal. We all know the endless struggle between wanting to point out a potential problem, particularly one which is holding up our progress, and fearing coming off as unprepared at the least, or arrogant at the worst. (“Surely this must be a problem with your software!”) The same holds true for the point on user investment: programmers are always “shopping” for useful tools and libraries, and I doubt that I am alone in being instantly turned off by an immediate failure to install, compile, etc. and continuing my search elsewhere.

Above all, I think the most valuable part of the post is the reminder to developers to keep a minimalist approach in designing their software and to try installing their work themselves. Of course, as the authors of the code, they will be far better off in debugging installation problems than the average user, but will at least be alerted to the obvious problems that may be encountered. This strongly relates back to the third reason mentioned above: while developers of open source software are not under any obligation to make their software easily usable, if they have any pretensions to develop a community around their work, they have to realize that they will lose many potential users and contributors if their project and code are nightmares to work with and understand.

On a funny side note, I learned a new Internet abbreviation/slang from the post: RTFM - Read The …ahem… Manual. You can imagine what the F stands for, but I am just glad I didn’t encounter this term the hard way!

Contributing to Wikipedia:

In last week’s blog I mentioned that I made my first two contributions to Wikipedia, and it was a surprisingly exciting experience. In some way, these contributions were like visiting a “tourist attraction” in your own hometown - like visiting the Empire State Building for New York City natives. We all write those activities off as pedestrian, seeing so many others make the trip and knowing we could do them any time, yet more often than not, if we take the time and make the effort, we have a lot of fun and learn a lot as well.

A few points stood out to me as I tried to find my first opportunities to contribute. My first stop, as I mentioned previously, was the Military History WikiProject’s Open tasks page and I spent quite some time combing through the articles under the “Need Work on Grammar” section. Pretty quickly I found myself running into three issues. First, I noticed that many articles did not seem to have obvious issues with their grammar or any indications of such on their respective Talk pages. This could be because these pages have been edited since their tagging and no one got around to removing the grammar tag: I would consider doing this myself but it felt like too bold of a move for a rookie. Second, in some cases where I did find some potential issues, I felt uncomfortable trying to make any changes as without further specific domain and conventions knowledge, I did not want to risk making poor changes. Third, on a related note, it seemed that a fair number of regimental pages - namely the American Civil War era units - listed by the project drew heavily upon unit histories and read more like logs or lists than true articles (ex: see the 1st Maine Battery). I would love to help but, again, fearing understating, embellishing, or missing the point entirely - all very much possible when you don’t understand something - I opted to move on to something with a better base on which to build.

Thus, in the end I chose to make changes to developed, but still somewhat lacking articles on the USS Mahan and the M2 Bradley. One last point of interest is that in the course of looking at the USS Mahan page, and other Wikipedia articles on other ships, I saw the ships frequently referred to as a “she”. In truth, I know full well this a longstanding tradition but I have always struggled to refer to inanimate objects as anything else but “it” and, with Wikipedia’s emphasis on being a neutral source fresh in my mind, I wondered if there was an official policy on this practice on Wikipedia. It was fascinating to find that there is a page dedicated to all the discussion pages on this matter, and that, at least at the end of the most recent discussion, the resolution seemed to be that this practice, as with many conventions on Wikipedia, should be left where dominant and perhaps discarded in newer articles.

FOSS Project Log:

This week I took my one (and thankfully only) midterm of this semester in a challenging but excellent course on computer vision. Hours of review questions and intense studying, finally coming to terms with things that puzzled me in the lectures, took up the majority of the week, as did catching up on internship time and other work, so unfortunately this week’s log is going to be quite short.

Sunday, March 29

What little time I could spare this Sunday went towards searching through issues in the Atom Github organization. This was both to meet last week’s stated goal of making sure that any issues we submit on the Atom Flight Manual would not be duplicating any existing issues, and for beginning to develop a new list of coding issues that we could dive in on.

Other Course-Related Activity:

This week I edited a fellow classmates’s blog. I had intended to make an additional two contributions to Wikipedia but have not yet had the time - they will have to come in the next couple of days!