If You Build It, They Will Fork It

Tags

,

Introduction

Open source software has become a driving force in the information technology world.

Few modern commercial enterprises earn significant money from software licenses. Instead they sell hardware, provide customer-focused consulting and support services, or use software applications to connect marketers with consumers.

Thanks to several ad-hoc communities clustered around various open source software ecosystems, developers have access to many flexible software tools to help them develop and manage even more software.

Often if a developer’s exact need is not fulfilled by an existing software tool, the developer can adapt an existing product to meet their need. This adaptive process often starts with the creation of a fork copy of the existing product, followed by independent developmont on the forked branch.

This article describes how I was able to meet my need for a NoSQL document database browse/edit tool for use with Couchbase by building on the work of another developer. This provides an example of the good side of forking a software product. I will also discuss the dark side of software forking.

The Unmet Need

Our software team uses Couchbase to store much of our application’s data as JSON documents.

The standard Couchbase installation provides a web console application that works quite well for creating buckets to store our JSON documents. It also works well for defining materialized views to provide alternate query index keys for our documents.

The standard Couchbase web console supports directly viewing a document if you know its exact primary key, known as its meta.id. However, that document viewer is actually a simple text editor for the JSON contents, and the editor in use cannot display documents larger than 2.5 kB (about 2,500 characters).

The standard web console for querying views has a display-only control for documents, but it takes several steps to configure a query, run the query, and then select a specific document to view its contents. If you then want to edit the selected document, the 2.5 kB limit still applies.

The Imagined Tool

Our team of developers has been considering how to create our own web application to use internally to more conveniently view, and occasionally edit, our JSON documents stored in Couchbase. For several months we never got around to the task.

We wanted a basic tool that would let us pick the full set of documents in a bucket, or the subset defined by a view, and view a paged list of their primary keys.

We imagined the ability to quickly view the existing contents of a document in the list, and optionally open it for editing.

When opened for editing, we imagined the option of editing the raw JSON text, or using a structured outline editor that supported the nested maps and lists inside a JSON document.

A Related Motivation

My role on our developer team normally focuses on server side components. I am quite comfortable developing web services using either REST or SOAP interface conventions, using several technologies such as ASP.NET, Java, and Node.js.

I decided to increase my familiarity with current practices in browser-based user-interface application technologies.

For a few years, it seemed the developers on my team that focus on the user-interface components had subscribed to some “JavaScript Framework of the Month Club”. Based on past experience, I was willing to let the dust settle a bit and see of any of the competing technologies might emerge as somewhat stable, and possibly dominant.

The Dark Side of the Fork

Which brings us to the dark side of open source software:

Sometimes, just as one competing framework or technology starts to become one of the top 2 or 3 in a pool of similar products, someone creates a fork or branch of the product. If that new fork starts diverging from the original product, the developer base for the original may divide into two smaller camps. This often lowers the ranking of both branches of the product within the pool of similar products.

For developers already familiar and invested in the original product, a dilemma can occur as to which fork receives their loyalty.

New developers (our experience developers updating their technology skills) experience an even larger frustration. Imagine considering 5 competing frameworks that fill a similar need. Suppose 3 of those frameworks each fork into 2 separate products. Now you have 8 frameworks to choose from for your first project in that technology area.

This xkcd cartoon laments a similar issue with software standards.

Which One Should I Use?

When it comes to browser-based JavaScript user-interface frameworks, there is a wonderful site ToDoMVC that catalogs several alternate implementations of a basic To Do List application. The home page lists approximately 20 dominant choices. The full Examples on GitHub contains about 40 choices.

This is why I evolved my just-in-time learning philosophy after several decades of software technology churn. Unless I have a current or upcoming need to work in a given technology area, I only focus on building a high-level awareness of the various competing options. Once an actual need arises, I review what appear to be the currently active options, and try to pick a good one.

The developers on our team have converged in the last year on AngularJS so I decided to give that a try.

I downloaded two different ToDoMVC examples that used AngularJS, and made some modifications to see if I could make it do some different things. I was starting to feel I could become a functional novice with that framework, especially since I could receive guidance from my teammates with experience in it.

Open Source Provides a Big Revelation

Once I had my ToDoMVC example application doing a few new things, I was getting comfortable with the AngularJS approach to things, including its naming-convention pattern for tying different elements together.

I decided to see if I could have it store its “To Do” text entries as structured JSON documents, as a simple approximation of an actual NoSQL document database. So I went web searching for a structured JSON document editor written in JavaScript.

After trying a few live demos, I discovered JSONeditor and was particularly impressed with its JSONeditor Online demo.

The next challenge would be to get AngularJS to play nicely with this JSONeditor. After a little more searching for AngularJS examples, I came across Shaun Xu’s blog article Create an AngularJS UI Module that describes how he created an AngularJS directive to integate JSONeditor. Open software for the win!

It gets better: Shaun Xu integrated JSONeditor with AngularJS for a web-based document browse/edit application for Microsoft’s Azure DocumentDB, as described in “My DocumentDB” – A Simple Web-based DocumentDB Management Tool

In the best Open Source Software tradition, I had a fully functional application that works with a similar NoSQL document database product to use as my launchpad for a related application to work with Couchbase.

The Fork in the Road

I created my own fork of Shaun Xu’s GitHub repository and gave it the name cb-bread. This stands for “Couchbase Browse/Read/Edit/Add/Delete”. I chose the “BREAD” acronym rather than the usual “CRUD” (Create/Read/Update/Delete) for purely aesthetic reasons.

My technology comfort zone includes Node.js REST-based web servers and various database technologies. Replacing Shaun Xu’s Azure DocumentDB back-end with a Couchbase back-end fit quite well in my area of expertise.

As already described, the standard Couchbase web console serves quite well for creating and administering buckets and view definitions. I removed the analogous features that were present in Shaun Xu’s My DocumentDB as I refined cb-bread. (This exercise allowed me to increase my understanding of the AngularJS framework.)

The Result

Here are some screen shots of the finished cb-bread application:

The startup/login page:

startup/login page

The list of Couchbase buckets:

list of Couchbase buckets

The list of views in a bucket:

list of views in a bucket

The list of documents in a view:

list of documents in a view

An expanded document in the list:

expanded document in a view

A document being edited with the JSON outline editor:

JSON outline editor

A document being edited with the text editor:

document text editor