DataLoader
I created the first prototype version dataloader.io and then helped led all early development of right after joining MuleSoft. The goal of this ecosystem project was to serve as a demonstration of the security and scalability of the first MuleSoft cloud offering called CloudHub, as well as drive brand equity value and awareness around MuleSoft generally.
This overall ecosystem project led significantly to Salesforce Ventures investing in MuleSoft, as well as the eventual acquisition of MuleSoft by Salesforce in May of 2018 for $6.5B, Salesforce's largest acquisition at the time by a factor of two.
dataloader.io was the first Salesforce AppExchange application to support "Login with Salesforce" with OAuth, and quickly became the most popular application on the Salesforce AppExchange for over five years, and the most used data loading tool for Salesforce of all time used by a majority of all Salesforce customers. I presented it at Dreamforce in 2014 with the Salesforce product management team.
As for more of the backstory, when I first joined MuleSoft in 2011 as the first Salesforce Architect at the company, the primary product offering of the company was the open source Mule Enterprise Service Bus (ESB), based on an implementation of a Staged Event-Driven Architecture (SEDA), and a library of reusable enterprise integration patterns accessible in a high-performance lightweight Java runtime.
More than a specific technology, an ESB is an architecture for enterprise to avoid "point-to-point" integration, which Ross Mason, the founder of the open source Mule project and MuleSoft company, would call "evil". Salesforce and others eventually came to agree.
The Mule core runtime was used almost exclusively by Java Enterprise Architects at very large enterprises, and therefore wasn't very well known outside of use cases in that realm. The company and especially its investors wanted to make the shift to the cloud, and further to become relevant to the overall cloud computing ecosystem, where Salesforce was by far the largest cloud-based business application provider.
Having been a Salesforce Architect for five years prior to joining MuleSoft, involved with over fifty highly successful Salesforce project implementations across a wide range of different industries, I knew first hand that CSV upload was the primary form of integration use case that most Salesforce developers and customers cared about.
When I first joined MuleSoft, I found out there was already a nascent effort inside to standardize and productize a database to Salesforce integration using Mule. I felt strongly that for MuleSoft to enter the cloud market, we needed to expand beyond application integration use cases common with ESB implementations, and enter the realm more of data integration that CSV use cases represented, and to do it with cloud scalability and security.
And so I created a simple first prototype, which was a single page application (SPA) that allowed submitting a CSV to be parsed by Mule and then inserted into Salesforce using API calls.
I demoed this to internal MuleSoft folks on the product, engineering, and executive teams, as well as to multiple teams at Salesforce. We fortuitously learned that there was an initiative inside salesforce to replace their internal sales force data loader tool.
Even as salesforce promoted the mantra of “No Software", one of the dirty secrets that every salesforce developer an architect knew is that every implementation utilized a very clunky salesforce developed product called the Apex Data Loader. This tool was practically universally reviled, given how finicky it was, and the requirement to use Micrsoft Excel VLOOKUPs extensively.
Given that Salesforce did not at the time consider themselves an integration company, their feeling was that to develop Apex Data Loader any further they would, by default, be entering into the integration space, and they didn’t want to compete with partners, such as Informatica.
So they developed a special program where they incentivized a number of partners to develop a replacement for the Apex Data Loader. The quid pro quo, was that they wouldn't pay for any development, but for any company that fulfilled the required specifications to achieve feature parity with the Apex Data Loader, would get their offering premier placement by being "hard coded" inside the Salesforce Setup configuration interface.
Over the course of six months, I worked closely with the product management, executive, and engineering teams inside MuleSoft, as well as, as well as many folks inside Salesforce on the product and engineering site to develop the first version of dataloader.io. I then recruited 25 or so experienced Salesforce MVPs and other administrators and developers to give us detailed feedback and build a matrix of all of the features to prioritize.
I secured commitments from lots of different stakeholders both inside Salesforce and elsewhere to tweet and promote the tool upon launch. The very first version had lots of trouble parsing the wide diversity of CSV file formats uploaded, which we quickly fixed, and within 3-4 weeks the tool climbed to the top of the AppExchange popularity listing, where it remained for over five years.
Scheduled integration support for Dropbox, Box, and SFTP were added, which drove further business development activity and adoption. The fact that Salesforce customers began using and loving a MuleSoft product, powered by its CloudHub Integration Platform-as-a-Service (iPaaS), dramatically accelerated MuleSoft's rise and investment by Salesforce Ventures, going public on the NYSE (MULE), and eventual acquisition by Salesforce for $6.5B.