Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

We jettisoned Pentaho about 2 years ago because of the effort required to develop and maintain it.

At the time, between the ETL and reporting layers, it acted more like a set of different open source apps simply branded together, and interop required more effort than what should have been necessary.

Debugging was a nightmare as well. Huge stack traces on simple errors made locating problems difficult, and there seemed to be little information in the community. The number of Java library layers spewing out on a simple JDBC driver error was mind-boggling. Pentaho of course has a interest in revenue from support contracts, and most inquiries into simple issues in the forums led down that path. It may have gotten better since, but there was a long way to go.

We switched to Tableau on the front end, and "old fashioned" ETL scripting in Python (now some Go) on the backend. At the same point today I would consider something like R/Shiny, but for speed of implementation Tableau would also be a contender.



Basically same here, but a few years earlier. I consider a three hundred line stack trace to be a valid reason to replace a system with something less operationally challenging. When engineers are $100+/hr, and some way more than that, it often ends up being cheaper as well.


The record setter I saw was 1,500 lines from two JDBC exceptions.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: