I wasn't a big fan of building open source software about a decade ago.

If you know me, have read any of my posts, or heard me speak at a conference over the last two years, you're probably aware of my immersion in chatbots. It all started with Microsoft's Bot Framework announcement, and transitioned into a technical deep-dive for a podcast episode on the framework. Ever since then, I've spent a lot of time writing and speaking about the technology, and when Microsoft announced the Bot Framework SDK v4, it allowed me to get in early on the latest version, the new tooling, and all of the changes. In fact, as a Microsoft Valued Professional, I was able to get an advanced NDA-bound look at this technology months before it was announced.

One of the things that I jumped at was the tooling: Chatdown, LUDown, MSBot. Building effective conversational applications requires more than just writing code. You'll likely be adding external services like natural language processing, but also need to effectively design the dialog flow. These are unique problems, as conversational applications are less structured by their very nature. Each of these tools--and Microsoft's new Bot Emulator--provide a way to connect various concepts, techniques, and technologies to create an end-to-end workflow.

One problem: I got in on the ground floor so soon that there were a lot of things that were incomplete.

Another problem? When you write code for a living (and a passion), and the technology you're working with is open source, you really have no excuse not to build it yourself.

Case in point: I built the first Node.JS module that consumed and parsed the *.bot file format a full several months before Microsoft implemented their own parser. Why? I needed it to complete some chatbot examples, and I had no excuse not to the look at the bot file creation source code and build a parser myself.

Where am I going with all of this? Let's take a look at a different example.

Chatdown is a Microsoft command line tool for processing Markdown-like syntax into chat transcripts that can be read by the Bot Emulator. This is a way to script out and design dialogs and interactions without actually having to build a prototype. The standard syntax to process a file is:

chatdown FILE_NAME.chat > FILE_NAME.transcript
    

The problem with this is that each file needs to be processed separately. There was no way to process multiple files. The first thing I did was write a PowerShell command to simulate this:

Get-ChildItem **/*.chat | ForEach-Object { chatdown "$(Split-Path $_.FullName)/$($_.Name )" >  "$(Split-Path $_.FullName)/$($_.BaseName).transcript" }
    

The problem was that the PowerShell command was verbose, and didn't work as an "in property" command in Visual Studio Code's task file. I had to place it in an external file. What else could I do?

Chatdown can be used as both a package inside of your code and as a command line utility. In fact, the Chatdown command line utility simply calls the package. I realized that I could create my own package to process multiple files. I spent some time reviewing Microsoft's code base, and then built (and published) a Chatdown Glob package to handle processing multiple files.

The package worked great, and eventually I handed it over to the Bot Builder Community, but something was nagging at me. I didn't like how I had to use two different command line utilities to process Chatdown files.

Since the Microsoft code is open source (and on GitHub), I opened up an issue asking for processing multiple files. I then offered to fold in the Chatdown Glob code, and the team lead actually assigned the task to me. Later in the week, I did a pull request on the official Bot Builder Tools repository, and not long afterwards, the pull request was accepted, and merged with the code base.

There it was… a handful of lines of my own code in an official Microsoft product. How surreal.

A decade ago, I didn't understand the value proposition of open source software. On top of that, I overvalued the idea of technology in its pure form. Programmers often worry that if they come up with innovative technology, it will somehow be stolen or used by others; They won't get credit, and it will somehow cost them money. Over the last ten years, I've come to the realization that most of the people who make decisions on product purchases, acquisitions, etc. care very little about technology. You built a framework? Great. But what have you done with it? It isn't about the technology, the framework, or some proprietary piece of code, but about what that technology enables. What are you able to deliver with it?

My thoughts on open source have evolved in much the same way Microsoft's has. Most of the code that I write outside of my job is open source because if anyone does check it out, maybe they'll contribute, ask questions, offer advice, or tell me it's terrible. Either way, it's feedback I wouldn't otherwise have, and if someone can deliver with my code where I can't, good for them.

The other value that this offers is with interaction. By working with Microsoft source code, and communicating with Microsoft team members, this has made me a better programmer, knowledgeable of how Microsoft organizes their teams and repositories. It enriches my own knowledge, which then becomes a boon to the company I work for. In the end, contributions to open source offer value to the programmer, the community, and the industry as a whole, and that's what it's all about: Moving things forward.