Christian Posta bio photo

Christian Posta

Field CTO at, author Istio in Action and Microservices for Java Developers, open-source enthusiast, cloud application development, committer @ Apache, Serverless, Cloud, Integration, Kubernetes, Docker, Istio, Envoy #blogger

Twitter Google+ LinkedIn Github Stackoverflow

What criteria do you use when evaluating whether to use a commercial product or open-source project to support your system-integration development? Is documentation near the top? To me it seems the commercial vendors pump out volumes upon volumes of documentation which makes finding what you need a needle in a haystack. On the other hand, open-source projects seem to have very little documentation and what they do have presupposes non-trivial knowledge of the project. Which makes total sense to me. The commercial vendors are trying to sell you on the multitude of capabilities their product supposedly has, so they better have reams of documents to show somebody. The open-source developers want to write code and expect anyone interested in their work to read their code. They don't want to be bothered writing documentation that will probably be outdated as soon as they make their next commit.

I wanted to quickly point out something that I've noticed to be quite different for the open-source projects supported by FuseSource. Apache ActiveMQ, Camel, ServiceMix and CXF have documentation at their Apache sites that varies in terms of quality. But FuseSource has put together top-quality docs for each of the aforementioned projects focused on helping the reader quickly come up to speed and understand how to use the important features of a product. And it's not just mickey-mouse examples either. They've put together examples gathered from years of experience consulting at various types of clients that focus on the intended way of using the product . When it comes to wanting to know how to use, for example ServiceMix, and the pitfalls to avoid and best practices to employ, having the FuseSource docs for ServiceMix (aka Fuse ESB) close at hand is a must.

Another thing that can frustrate developers is outdated documentation. You may find a page, even hosted at the project's website, that explains a certain way to develop a solution, but when you try it yourself, it doesn't work. You can spend hours trying to figure out what you did wrong only to find you're actually not supposed to do it that way anymore. The FuseSource documentation solves that by organizing all of the documentation for a specific version. When you click on a doc set for a particular version, you can be sure that the features and examples covered are specific for that version and not just clobbered together with whatever else used to work and is outdated.

The docs at FuseSource are tailored to help you quickly coming up to speed and are focused on solving problems with the technology without the unnecessary fluff to get in your way. If you are using ActiveMQ, Camel, ServiceMix, or CXF, I highly recommend checking out the FuseSource docs. If you don't use those products yet, consider that the documentation is an asset as you explore whether or not to use them.