Hobby projects mean hobby projects, not open source projects

“FusionCharts mocks open source but uses it extensively,” ran a headline on our Twitter feed yesterday. Curtis Poe, a freelance Perl developer and consultant from France, had written a blog post arguing that when we said “hobby projects don’t cut it for enterprise-grade applications” and called ourselves “JavaScript Charts for the grown-ups” on our homepage, we were taking a dig at open-source libraries. Not just open source charting projects, but the open source community at large. And that we had no right to do so since we use a lot of open source libraries ourselves. The discussion picked up steam on Hacker News and Reddit as well before we issued our clarification and peace was restored. But we thought it would be a good idea to clarify it in more detail on our blog.

What do you mean hobby projects?

When we say hobby projects, we mean just that. Hobby projects. Not open source charting projects. And definitely not open source projects at large. Many a time, as a learning project or for fun, an enthusiastic developer decides to build a charting library over a weekend, and release it to the world. Developers in other organizations looking for a charting library come across it, pick it up and start implementing it in their applications. At the beginning, everything works great. And given the fact that the developer didn’t have to pull out a credit card or ask the purchasing department to buy a license before getting started, everything seems to be perfect with the world. But as soon as the developer moves onto implementing advanced capabilities, he starts running into product limitations, cross-browser compatibility issues and bugs with important features. He goes back to the creator trying to get a fix, but it turns out that his day job is keeping him very busy and he has moved on from the project. At this point, if he wants to stick with the same product, he has 2 options—either extend the project himself or find someone who can do it for him— both of which will distract him from his main development, and delay the release of the application. Doesn’t sound like the perfect fit anymore, does it? We have been in business for over 11 years, and have seen hundreds of such hobby projects come and go. More importantly, we have seen a lot of organizations coming to us saying that the perfect charting library they picked up didn’t exactly turn out to be perfect, and buy a license from us. With 22,000 organizations who have paid for our products, you would agree that the sample size is decent. Add to that 500,000 developers who have downloaded a trial version of our products.

So what does an enterprise-grade charting component bring in?

As a business, when you are building an application, charting will most probably not be your core strength (if it was, you would be listed on our competitor comparison table 🙂 ). You want to focus on your core strengths, the main pain points your application solves. And that’s where an enterprise-grade charting component comes in. Not only does it cover you on the product part of things—you get a well-architected product that can be extended, features that have been built over years to be in tune with the ever-evolving data visualization landscape and real-life dashboards to inspire you—it gives you extensive documentation, personalized tech support and assurance of continued development. Let us touch upon each of them in a little more detail. With hobby projects, you get limited documentation on how to get started with the project, or use the essential parts only. But if you have to integrate with different server-side languages or client-side libraries, you’re left to figure that out on your own. Also, when you run into a bug, you wouldn’t always have the luxury of going around community forums trying to find a solution. You have tight release cycles to adhere to. And more often than not, there is little or no community to help you find a solution either since the project has been abandoned. What you need is a quick solution to the issue you ran into so you stick to your timelines. And that’s where an enterprise-grade charting component with its dedicated technical support team and assurance that the bug will be fixed. And finally we come to the point of continued product development. Data visualization is assuming more importance every single day as businesses and individuals alike are looking to make more data-driven decisions. As a business, what you need is continued product development that can keep the data visualization part of your offering at par with what the industry offers and what your users need, if not better. With a truly enterprise-grade component, you are assured of that.

Got it. What’s your stance on open-source?

We are not against open source at all. There are some good open source charting libraries out there, which we have listed in our comparison table of popular JavaScript charting libraries. In fact, we use a modified version of RaphaelJS as the core of our products, which we’ve open-sourced ourselves as RedRaphael. In addition, a good chunk of our own development tools and infrastructure are open source that you can find on our GitHub page. For example, we have built a tool to act as a preprocessor for JavaScript files, similar to the C preprocessor, called JSLink. We try to architect our internal tools in a way that they can be published as open-source and be used by the community. And yes, we use open source tools as well when they are a good fit for our requirements. We use JSDoc and Docstrap for generating our product documentation. We have open-sourced the improvements we have made to JSDoc as a separate repository for JSDoc plugins. Some of the useful changes we have done for Docstrap have been contributed back to the original repository. On the other hand, we are more than happy to pay for well-written tools and applications as well. Bitbucket, JIRA, SalesForce, Moz, 15Five, we are happy customers of all these products and more. Essentially, the idea is to find the best tool for the job, commercial or open-source.

Conclusion

When we say hobby projects, we mean hobby projects. Not open source projects. Through our tagline, we want to caution businesses against the use of hobby projects if their application needs to scale in the future. Hobby projects will just not cut it for them.