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.

Jitterbit looks interesting, but doesn't appear to be free. Maybe this is a change since this article first appeared, but their license is the Jitterbit Public License. It's based on the MPL 1.1, but if you look here:
http://www.jitterbit.com/Product/licensefaq.php
It sounds less than free. First part ok, but then it starts going awry:
Scott, your initial statement is wrong and we would very much appreciate to know how you came to the conclusion that Jitterbit is not free? If you look at the site http://jitterbit.com/Product/editions.php the Community edition is explicitly priced as free. Furthermore, the Jitterbit Community edition is the same software as the Jitterbit Professional Edition. As you can see, the only differences pertain to a commercial license that provides commercial support.
Users can get to the free product through http://jitterbit.com/Product/download.php or they can go directly to Source Forge http://sourceforge.net/projects/jitterbit. The Jitterbit development team continues to have one code base with a Community (free) license and a Professional (commercially supported) license. There are no plans to change this strategy. Jitterbit Professional Edition users also download their code from Source Forge.
With regards to the license and its interpretation you are spot on. We publish the license at http://jitterbit.com/Product/license.php and provide common Q&A about it at http://jitterbit.com/Product/licensefaq.php.
Developers that make significant contributions e.g. adding a new protocols or new services, should conform to the architecture of the product and provide those in separate program files (classes) as does the Jitterbit development team. Significant contributions can be sold and copyright applied. Furthermore, system integrators have already created Jitterpaks (pre-defined integrations in Jitterbit XML meta data) and use this to augment their service offerings. Nothing prevents them from copyright and reselling their Jitterpaks. Other developers have created their own installation of Jitterbit on platforms like SuSE - once again, nothing prevents them from copyright and reselling their work.
When developers go to the effort of fixing bugs or making minor modifications to the Jitterbit code, then they are already realizing value from Jitterbit. In such a case we feel it appropriate that these works be contributed back to the community.
Thanks for your feedback.
Ilan Sehayek, CTO Jitterbit Inc. (ilan.sehayek@jitterbit.com)
Hi, Ilan. Thank you for your reply. I appreciate the chance to discuss and understand better.
When I said Jitterbit doesn't appear to be free, I meant free as in meeting the free software definition. To me this is the most important point and the price is not an issue. From my reading on the subject, it seems the question of whether a license is free or not is if it satisfies the definition of free software. I don't think software can be considered free if you place restrictions on the reselling of it.
You mention above that significant contributions can be sold, but the FAQ that I quoted says that a module you sell must contain no modified source code -- that is, you must add new files and not modify any original files. And then even more explicitly, "if you modify code covered by the JPL [...] Despite your copyright, you can not sell derived code". This sounds like a restriction that puts the license at variance with free software.
I agree that bug fixes and changes should be shared and contributed back to the community, but this would still be accomplished if people sold their modified code, since this code would be covered by the same license and could be used by all.
I believe in the model of free software with paid support where people or companies are willing to pay for it. Large companies especially want to have someone on the hook for support and are willing to pay. I haven't looked at what Jitterbit can do yet, but if it is software that I might use, the freedom of the license is a key point. Jitterbit Inc. is here today to provide support and I think would have to be the preferred vendor, but a company that is looking to use free/open source software to avoid vendor lock-in wouldn't be gaining that advantage if the core source code is encumbered.
I haven't read the actual license -- I'm only going by the FAQ -- so maybe it's not my place to be speculating and commenting. But the FAQ seems very clear.
Again, thanks for your response. I'm glad we're starting to see free/open source software in the integration area. I don't mean at all to run Jitterbit down -- I'm just trying to understand if it qualifies as free software or just open source.