Jitterbit: user-driven integration, in-house Web 2.0, and another way to build a business on free software
Both I and the heads of Jitterbit battled torrential rains and the maze of Cambridge streets to make it to an early morning
meeting. It was well worth it. From this young company I learned a new way consultants and businesses might be able to make a living from open source. Furthermore, I saw an interesting play on the Web 2.0 concept–not for the customary mash-ups between different organizations’ offerings, but to integrate different backends within a single enterprise.
The field of system integration
The business of Jitterbit is integration, a headache in nearly any organization
large enough to bring in software systems from outside. For instance, you may be managing your products through an ERP system while storing product development information in a relational database. Virtually every organization has more than one backend, and is trying to get backends to work together.
Jitterbit President and CEO Sharam Sasson says that current integration products are suitable to only about 20% of the sites with integration needs, because its cost restricts it to the largest sites. But still it’s a multi-billion dollar business. He has the modest goal of solving a larger percentage of the problem–and of helping sites share their solutions in an open source manner so they can solve a lot more.
So Jitterbit itself makes free software (all its code is under a Mozilla license), but it additionally is trying to create a free space where users can contribute particular solutions. The Mozilla license allows companies that believe they
have particularly valuable solutions to keep them proprietary. The Jitterbit team doesn’t want to rule that out. But the coolest aspect of the system is the part that promotes a community of sharing solutions.
Integration doesn’t just mean “Make SugarCRM work with MySQL.” You will have a particular data set in SugarCRM and another data set in MySQL that you want to tie together. The task may be as simple as telling the systems that the field called Employees in one is called Staff in another. Or it may require complex filtering, as when the date formats used by systems differ.
The nature of integration is that each customer has N systems along one axis that have to be integrated with M systems along another axis; there are potentially NxM integration tasks. Raise your eyes to look at the whole IT world with millions of firms, and the NxM task becomes mind-boggling.
Yet there are thousands of firms that have to start with the basic “Make SugarCRM work with MySQL” integration. The Jitterbit team can’t solve all such tasks, so it wants to make it easy for users to do it for themselves.
The Jitterbit product and the Jitterpak standard
Like all integration products, and like the translation tools that customers painstakingly develop for themselves in-house, Jitterbit is based on writing interfaces that translate simple user input into the queries or commands that insert and extract information into each system being integrated.
The user experiences starts with a fairly simple graphical client (written in Java, to be cross-platform) where people add data stores, connect to them, and mark the fields they want to connect. My impression is that this would take a bit of getting used to, but would allow managers to integrate large amounts of data much faster than writing individual queries.
Jitterbit also offers an XSLT-like filtering language that lets users translate
data to a different format, or produce any other code they need to run when linking data in different systems.
Once the user has indicated that one system’s Employees field is another system’s Staff field, or whatever transformations are necessary, Jitterbit writes the information out to an XML file. This standardized package, called a Jitterpak, is the heart of the system and the key to its potential for building an open community–as well as a new business model–around integration.
Essentially, a Jitterpak preserves all the information needed to connect to two
different systems and share data between them. Once a user posts a Jitterpak to
a Jitterbit forum, other users can use it to solve the same problem at their sites. Typically, the other users would open the Jitterpak in their Jitterbit Client and make such changes as adding their address and authentication information so they can connect to the particular systems on their networks.
It’s interesting, from the standpoint of understanding innovation, to learn that the invention of the XML Jitterpak format was somewhat a matter of serendipity. This format was originally a hack developed for internal use, so that programmers trying to debug a problem could easily mail their work to other programmers for review. Eventually, though, the company realized that the format was the most powerful tool they had for promoting user participation in the project–and thus it turned into another example of the resiliency of open source.
As mentioned, Jitterbit wrote a lot of the glue that turns user input into queries on various popular software systems. Experts in each system could make a business out of writing Jitterpaks for various tasks within the NxM grid I introduced earlier. Thus, the Jitterbit heads hope their tools become a fertile ground for a new crop of businesses and consulting firms that solve integration problems
and provide a living for free software developers.
One of Jitterbit’s corporate collaborations shows how it can give a boost to Open Source businesses. One of its customers used it to map some open source systems to an open-source ERP aimed particularly at manufacturers: OpenMFG. Jitterbit eventually formed its own relationship with OpenMFG, streamlining the integration process for other OpenMFG customers. In short, it removed a huge amount of the overhead that OpenMFG or its customers would have to expend if each customer had to do the integration individually.
Jitterbit encapsulates the nuts and bolts of connecting to each proprietary system in a language that they hope to standardize and publish an open specification for. But many systems already provide a standard interface for connectivity: a
SOAP-base Web service. Such systems are ahead of the game; they make it much easier and quicker to develop Jitterpaks. And thus Web 2.0 can help a company integrate its own systems as much as it can help someone interface to a foreign site
such as Amazon. Jitterbit expects its tools can be useful in the larger, inter-organizational SOAP space too.
Jitterbit, the company
Version 1.0 of Jitterbit was officially announced today. The company started in
December 2003 and now has ten employees. They are headquartered in Alameda, California.
Jitterbit believes it can build a robust business on support and maintenance, which makes sense because each site has a unique combination of NxM integration tasks. This is why they’ve decided on the Mozilla license, instead of a dual license model where sites that want to offer products based on Jitterbit would be forced to pay them.
I like Jitterbit for many reasons. They’re finding new ways to earn money–not only for themselves but for others–in an open source environment. They’re finding a new way to apply Web 2.0 concepts. they’re committed to open standards, including plans to contribute their own work as a standard. And they’ve found a way to blur the development lines between their own team and their users in a way I think Eric Von Hippel would approve of.