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.
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?
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.
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.)
Here are some screen shots of the finished cb-bread application:
The startup/login page:
The list of Couchbase buckets:
The list of views in a bucket:
The list of documents in a view:
An expanded document in the list:
A document being edited with the JSON outline editor:
A document being edited with the text editor: