Monday, May 22, 2017

To each their own (literal parse!)

It looks like I'll be playing around ballerina for a while more, its only fair I document some of my experiments for prosperity sake, especially considering there is a lack of content on the subject, but this blog is probably not the best place to do that. So if you're interested in hands on reads on Ballerina find them here:

Tuesday, May 2, 2017

Three types of quotes in the world..

If you’ve dealt with the Linux shell it’s very likely you would have come across different types of quotes. They mean different things to the shell and as such they are handled by it in different ways. Here’s a quick review.

Tuesday, April 25, 2017

Error Handling and Functions with BASH

BASH[1], to my understanding is not meant to be used as a general purpose programming language and attempting to use it for such purposes can lead to tricky situations. Having said that, for the sake of argument let’s assume you need to use it for such a purpose. Here's how you can do some of the housekeeping tasks with it.

Error Handling and API Calls

Process exit codes can be used to do a quick assessment of successful completion, however it should be kept in mind that checking the  error codes alone cannot guarantee output is error free and as you expect it to be.

“?” env variable contains the exit code for the last run process in session, where a 0 denotes a successful process exit while 1 denotes a failure. This variable when coupled with conditional statements can bring in some basic error handling capabilities to your scripts.

API calls can be made using the cURL HTTP client. This package comes installed in many Linux distributions but it's advisable to do a check for availability using the package management tools available in the system.

A simple way to validate API calls would be to utilize the -v flag in cURL client to print out a verbose output and then redirect the output to a grep to be asserted for a predefined value.


Bash provides limited capability to abstract out code to create functions, find more about its capabilities with regard to functions here[2]. As BASH is not capable of creating user defined data types, you might find yourself in a situation where you need to return a bunch of data items back to the caller. A crude way in which this requirement can be achieved is by dividing the data items with a unique delimiter and then breaking up the values on the caller side using awk.

When you start resorting to elaborate methods to get simple tasks done, you are probably extending BASH beyond its capabilities and it’s time to move onto a more capable language such as python.

[1] -
[2] -

Wednesday, March 8, 2017

Barriers to FOSS adoption and the role of the provider

A couple of weeks ago I posted a writeup on why organizations can’t afford to ignore open source anymore, the write-up was based mainly on my own experiences and knowledge I came to possess as a result of working for a product company that is built around an open source business model. Towards the end of the writing process, I felt there is a lot more that can be said about FOSS, especially concerning adoption and the role providers play in assuaging adoption pains.
As discussed in the previous post[1] the drive for Open Source adoption in organizations can come from the industry or broader technological community manifested as ground level traction by the in-house engineers. This driver was looked at by Miralles, Sieber and Valor. Two types of technology adoption views were considered in their research. These two views being,  technical push; a deterministic view, where the decision to adopt is mediated by an accumulation of factors such as technical attributes, the cost of ownership and ability to transition into open source. Organizational pull; factors intrinsic to the organization such as organizational capabilities, vendor-organization match and psychological factors of the decision maker. The research found FOSS to have a greater technical push compared to its proprietary counterpart, in all areas except lock in(ease of transition) but in most cases, it was beaten off due to low organizational pull when it came down to the decision to adopt(2006). This study was done a decade ago, it would be interesting to see if the strength of correlation between the technical push and the decision to adopt has changed over time, looking at the current technological landscape one can assume it has gotten stronger.
The technological superiority of FOSS has been discussed in countless research papers and countless more web articles. Furthermore, even if the strength of correlation between technical push and decision to adopt has gotten stronger from the time the research in question was done, common sense dictates the factors looked at in organizational pull should have a stronger relationship with the decision. The decision to adopt therefore should be made by assessing the potentialities through both views. This is where I feel FOSS is lacking, its ability to convince that it is the right choice regardless of the view one adopts when assessing it. The purpose of this post is to point the reader on how the shortcomings of FOSS can be circumvented through the services of a provider.
Before we can address how a provider can address the drawbacks of Open Source and other barriers to its adoption, we should have a better idea of these drawbacks and barriers. Hauge et al found Lack of support and expertise, difficulties in selecting the right OSS products and ambiguities in liability as major barriers to adoption.(2010) Morgan and Finnegan found compatibility issues, lack of expertise, poor documentation and lack of roadmaps and other documents pointing to strategic direction of Open Source projects as technical drawbacks. Moreover, the researchers found a lack of ownership, a lack of support and difficulties of finding right staff/competencies as business drawbacks.(2007) As mentioned in an earlier paragraph, Miralles, Sieber and Valor highlighted the following three organizational barriers. Organizational capabilities; concerns regarding in-house expertise on the technology and the logistical/operational constraints of building up expertise. Network externalities; the indecisiveness that one might feel due to the phase of evolution in open source. Psychology of decision makers; factors such as the impression adoption decisions of peers have on your own and other individual differences.
Providers such as Red Hat and WSO2 build value on top of FOSS by addressing these shortcomings and drawbacks, providing products that are better tailored to enterprise needs. Providers that have adopted similar open source business models provide paid auxiliary services on implementation, support, maintenance and consultation. These auxiliary services may be availed to a great extent by any organizations considering Open Source adoption but discouraged due to its perceived drawbacks. 

Lack of expertise,

Product expertise will be needed by organizations at various stages of their technology adoption and transition journeys. The specific needs pertaining to expertise at one point of the adoption journey can differ from another, therefore organizations evaluating providers should look into the potential provider's ability to cater to these varied needs.     
Providers should be able to address concerns about an organization's in-house expertise with focused on site consultancy services, documentation, and other training resources. Furthermore, The providers should possess the competency to address concerns that may come about at different points of adoption that are specific to the organization's existing technological infrastructure. Lastly, the providers should have dedicated channels(such as support channels) to disseminate the expertise.
Organizations, in turn, can put programs in place to cultivate in-house expertise of the products, leveraging the documentation and other learning resources provided as value additions by the providers.      

Compatibility issues and concerns of lock-in,

Organizations may get discouraged by possible compatibility issues between FOSS and their existing technological backbone. Though this is a concern that is common to both open source and proprietary software in adoption and transition, in the case of open source, the access to the information needed to decide on compatibility may be hard to come by. Therefore, organizations should be able to get the assistance of the providers when they are evaluating the possibility of adoption. Dedicated channels should exist for organizations to access the information from the providers. Organizations should opt for providers that assist in this evaluation process, some providers may even provide specialized services catered for this very requirement.   
Considering the comparatively low cost of ownership, It may be worthwhile for some organizations to purchase lower tier support/assistance services purely for compatibility evaluation. Organizations may avail these services to run pilot projects with the products, the benefit of such pilot projects are twofold as they will build up in-house competency on the technology.
Some providers may even offer their products as SaaS offerings, organizations evaluating OSS may use these services to get a better idea of functional compatibility of the products. Though it should be noted that at times the functionality of such SaaS offerings may be cropped to improve suitability.    

Concerns with liability and longevity,

As FOSS is maintained by a community unbound to organizational goals and needs, many organizations find liability as a barrier to adoption. Therefore, organizations should expect the providers to address these liability concerns with contractual obligations such as SLA's. Organizations should look to dedicated L1, L2 support from the providers.
As with proprietary software adoption, it makes sense to place the responsibility for the adopted technology between internal resources and external resources of the provider. Some providers may be able to provide dedicated agents that can integrate into the in-house teams to address concerns on behalf of the organization with the provider.
It makes sense to go with a provider that has been in the domain for a considerable length of time and proven domain expertise. Furthermore, organizations may look to the provider’s product strategy through product vision documents, roadmaps and such when assessing longevity.   

In summation, it is my personal opinion that many of the barriers to adoption that prevent the organizational pull favoring FOSS can be addressed with the assistance of providers, with a thought out adoption plan on the adopter's side and the backing of the right provider. That, those organizations that embrace Open Source as discussed in this post would have an advantage over those who have opted for proprietary solutions.

List of References

Hauge, Ø, Cruzes, D. S., Conradi, R., Velle, K. S. and Skarpenes, T. A. (2010) 'Risks and Risk
Mitigation in Open Source Software Adoption: Bridging the Gap between Literature and
Practice' IFIP Advances in Information and Communication Technology 319(1), 105-118

Miralles, F., Sieber, S. and Valor, J (2006) 'An Exploratory Framework for Assessing Open
Source Software Adoption'. Systèmes d'Information et Management 11 (1), 85-111

Morgan L., Finnegan P. (2007) 'Benefits and Drawbacks of Open Source Software: An
Exploratory Study of Secondary Software Firms' The International Federation for
Information Processing 234(1), 308-311      

Monday, February 27, 2017

Open Source, why organizations can’t afford to ignore it?

A couple of weeks ago I ended up here and it occurred to me that for the last year or so I had published posts ranging from WSO2 product related how to’s(what this site was initially supposed to be about), linux how to’s that bordered on immaturity to opinionated tech event reviews from my local community. This thought led to me changing the blog’s name to "The FOSS Merchant".

FOSS stands for Free Open Source Software, think Apache(no, not this guy[1]) and Ubuntu. “Free” in in this context mean something closer to “free speech” than “free beer”. Exercise your linguistic demons here, if you must[2]. Since “FOSS Merchant” sounds like an oxymoron, I thought I should write a few words on the matter.


Open Source Software, as it’s name suggests is free to be used and worked on by anyone. Meaning, most open source software projects are maintained by a community spanning organizations and geographical boundaries. This facet of open source software makes it more sensitive to industry demands and needs, it makes it evolve faster. In brief, organizations that tap into this quality of open source could, in turn, use it to increase their technological agility. 

The days when open source software was considered a plaything for the geeky and not a contender for the professional is far behind us. At present 1 in 3 servers[2] powering the internet is run on Linux and the number keeps rising every year. In fact one survey found Linux to be preferred by 78% of participants(including some fortune 500 companies) for their cloud-based endeavors[3], this figure makes sense considering the popularity of server crafting tools such as docker and the extended support it provides to Linux. Furthermore, there are plenty of examples of product companies that have successfully worked open source into their business models, from Red Hat estimated to be worth 14 billion USD, Oracle’s acquisition of MySQL at 1 billion USD, last week’s news of MuleSoft’s 100 million IPO to WSO2’s 11 year track record of providing leading middleware solutions and driving digital transformation[3] for organizations.             

A common accusation made against FOSS is that it is not as polished or as user friendly as it’s  closed source counterpart. Although this is true on occasion it is my personal opinion that this characteristic of open source software attracts the kind of engineer that end up having a bigger say in technological decisions at ground level, thus they drive organizational changes in terms of technology in the long run(common sense dictates its better to ride this wave than to expend energy redirecting it). This hypothesis is backed by some empirical evidence. In one survey done by The Linux Foundation[4] 52.7% participants cited in house expertise as a key driver for OSS adoption. In another study done on the adoption and transition from closed to open source software, based on the Technology Acceptance Model(an information theory dealing with technology adoption) found a negative correlation between the perceived ease of use and adoption of OSS in the public sector[5]. It is also easy to assume this hypothesis, as one of the factors for the phenomenal success of GIT version control system, when one takes into account the fact that it was considerably different(conceptually and in usage) from other version control systems of the time and was often accused of not being user friendly.

Other than the agility and ground level traction that can be expected by selecting OSS(as discussed in preceding paragraphs), organizations may also take comfort in knowing they have complete access to the code base of the software they are procuring, this may not even be an option with some proprietary vendors. This disclosure coupled with in house expertise on the code base which can be cultivated, in time can amount to technological independence and assurance for the organization. 

However, OSS posses its own novel set of concerns which organizations should address before making the transition. As most open source projects are maintained by volunteers, they lack documentation and other knowledge resources which organizations need to make informed decisions on suitability. Tailoring the software to exact organizational needs and maintenance afterwards may prove to be difficult,  as expertise on the software cannot be readily accessed. As this is the case for many open source projects, it is of paramount importance that organizations select a commercial OSS vendor/partner that can bring in value by addressing these concerns. Furthermore, commercial OSS vendor/partner’s more often than not provide useful features that cannot be found in the original projects. 

Tuesday, February 21, 2017

A Caveman's Bash Editor

WSO2 is in the process of improving its CI/CD pipeline in preparation for a bunch of new products(btw did you hear about our exciting new integration language? find more information here: and yours truly was given the awesome responsibility of creating a jenkins post build shell script inline with this goal. During this process I noticed a serious lack of tools for shell/bash script writers and so i wrote this simple helper script.

bash script
vim script

How to get it working,

  1. Install vim if you don’t have it in your box.
  2. Copy the vimrc file to $HOME/.vim/
  3. Move to a location of your liking and run it providing the bash script that needs to be syntax checked as a script parameter e.g. ./ /home/dumiduh/
  4. Leave the script running and refer to it while editing your script(Refer screenshot below).


  • The script uses ‘bash -n’ linux command and will only pick up syntax errors it picks up.
  • The vimrc file changes the vim editors behavior so that it automatically saves changes, this behavior can be a pain at times so remove the file from $HOME/.vim/ when the script is not used.
  • The script was tested on Ubuntu 14.04 with vim 2:7.4.052-1ubuntu3

Tuesday, January 31, 2017

Thoughts on the SLASSCOM Blockchain Event

When will I find a better place to keep these write-ups?

Blockchains and bitcoins are two words that have been thrown around for while, I know little about either and so to fix the situation I decided to attend a blockchain knowledge sharing session organized by SLASSCOM.

To be honest, I have tried figuring out bitcoin when it first popped up as a buzzword but the effort didn’t really lead to any substantial gain in my knowledge on the subject. Now, in retrospect, I can see that it turning out the way it did had more to do with the way in which I went about figuring it out than any other reason.

Here’s the deal, what I figured out during the session was that 'blockchains' is one of those topics that should be looked at conceptually than from an implementation point of view when you first go about trying to wrap your head around it. If you focus on the underlying implementation technologies too much you miss the point! From a technological point of view, blockchains are not doing anything radical or new for that matter. As far as I could understand they are mostly using batch processing technologies and proven security concepts that are old as the hills. Maybe it was because of this reason that I found it a little hilarious when two audience members tried to make it look like it’s just about security, in my humble opinion they added noise to the session(more rants on a similar subject here)

What one should understand instead is what it tries to accomplish and what benefits it has over what’s existing, cash money(yo!) One needs to understand concepts such as what is money? What does a 100 rupee note really represent? Concepts that don’t come to us engineers too naturally.

Blockchains are a huge one up on paper currency because it provides absolute traceability and improvements in authenticity. All four speakers were competent on the subject and delivered their segments well. I was especially impressed with the segments Jayamin Pelpola from Alfinity Ventures and Tharindu Dissanayake from MillenniumIT delivered as they were focused more on real world implications/experiences, areas of future growth and were driven more towards getting the concept across, which I felt was best suited as the topic is a lot more novel conceptually than technologically. Though it must be stated that Omega Silva from VirtusaPolaris did a great job of explaining the technical nitty gritty.

Bottomline, Blockchains can be used as a tool for organizations to optimize situations where they need to process money or other tokens that needs to be held in the same light and add an additional level of integrity and authenticity to transactions. But for you and me Blockchains wouldn’t really make a difference either way for many many years to come. It is only if and when blockchain systems such as bitcoin become adopted(or projected to be adopted) by a majority would you and I really reap benefits of trading in the metal coins in our wallets for their digital counterparts, regardless of how accurately they can be tracked down to their origins or significance of their processing improvements.

Yet another great event by SLASSCOM.