4 ms·

What effect does the code base have on adoption for a OSS internal tool? ToolJet - rails / react AppSmith - Java / react? Budibase - node / react? - correct

What effect does the code base have on adoption for a OSS internal tool? ToolJet - rails / react AppSmith - Java / react? Budibase - node / react? - correct me if those are wrong. But we were looking at these tools internally recently, and there were many factors in the decision (sso & self hostable being big ones). But I’m interested to know from others the extent to which code base & framework decisions of the tool impacted adoption decision.

navaneethpk 4y ago
Stack matters a lot if the project is open-source. We migrated ToolJet's backend from Rails to node after the beta launch last year. We've documented the thoughts behind out decision here: https://blog.tooljet.com/migrating-toojet-from-ruby-on-rails-to-nodejs/ https://blog.tooljet.com/migrating-toojet-from-ruby-on-rails.... The benefits that we got: - Contributions from around 200 contributors so far. - We built a plugin system and plugin development kit that helps community build plugins for ToolJet. ToolJet anyway is extendable via JS ( use JS anywhere on editor, run custom JS snippets, bring your own React components, etc ), stack also being 100% JS/TS made sense for us.
krn 4y ago
> But I’m interested to know from others the extent to which code base & framework decisions of the tool impacted adoption decision. I tend to judge the technical foundations of an open-source project by the programming language it is primarily written in. From my experience, the highest quality implementations these days come either in Rust, Go, Clojure, Python, or TypeScript. For older and well-established projects, it's usually C, C++, and Java. I think what's important here, is not only the performance and the design of the programming language, but the entire ecosystem around it. I am much more likely to rely on an open-source code that itself relies on high quality battle-tested dependencies.
- bogdanu 4y ago
  I'm thinking about starting an OSS project as an alternative to Greenhouse and the likes (applicant tracking software) in written in PHP, as that's my main language at work. However, I'm a bit relunctant seeing the hate the language gets even though I would use a modern framework like Symfony or API-Platform.
  - krn 4y ago
    When you are building a SaaS product that only runs on your servers, you can use whatever you want. But when you are building an OSS product, there are a couple of more things to consider: those who will run it, and those who will contribute to it. For instance, I love the idea of Nextcloud, but I would neither run it, nor contribute to it as long, as it is written in PHP. Currently, there are 161 comments on Hacker News with the words "Nextcloud" and "slow" in them: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Nextcloud%20slow&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... The same applies to Gitlab, which is written in Ruby and runs on Ruby on Rails under the hood. Currently, there are 1,656 comments on Hacker News with the words "Gitlab" and "slow" in them: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Gitlab%20slow&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... Had they made the right technological choices from beginning, there would be no need for articles such as "Why We’re Sticking with Ruby on Rails at GitLab" in 2022: https://news.ycombinator.com/item?id=31684529 https://news.ycombinator.com/item?id=31684529 With the CEO of the Gitlab admitting in the comments: > Performance is indeed worse. We're moving the 20% of the app consuming 80% of the compute to Go.
  - ipaddr 4y ago
    You should. I wouldn't consider a project not in php and applicant tracking is important.

navaneethpk 4y ago

Stack matters a lot if the project is open-source. We migrated ToolJet's backend from Rails to node after the beta launch last year. We've documented the thoughts behind out decision here: https://blog.tooljet.com/migrating-toojet-from-ruby-on-rails-to-nodejs/ https://blog.tooljet.com/migrating-toojet-from-ruby-on-rails.... The benefits that we got: - Contributions from around 200 contributors so far. - We built a plugin system and plugin development kit that helps community build plugins for ToolJet. ToolJet anyway is extendable via JS ( use JS anywhere on editor, run custom JS snippets, bring your own React components, etc ), stack also being 100% JS/TS made sense for us.

krn 4y ago

> But I’m interested to know from others the extent to which code base & framework decisions of the tool impacted adoption decision. I tend to judge the technical foundations of an open-source project by the programming language it is primarily written in. From my experience, the highest quality implementations these days come either in Rust, Go, Clojure, Python, or TypeScript. For older and well-established projects, it's usually C, C++, and Java. I think what's important here, is not only the performance and the design of the programming language, but the entire ecosystem around it. I am much more likely to rely on an open-source code that itself relies on high quality battle-tested dependencies.

bogdanu 4y ago
I'm thinking about starting an OSS project as an alternative to Greenhouse and the likes (applicant tracking software) in written in PHP, as that's my main language at work. However, I'm a bit relunctant seeing the hate the language gets even though I would use a modern framework like Symfony or API-Platform.
- krn 4y ago
  When you are building a SaaS product that only runs on your servers, you can use whatever you want. But when you are building an OSS product, there are a couple of more things to consider: those who will run it, and those who will contribute to it. For instance, I love the idea of Nextcloud, but I would neither run it, nor contribute to it as long, as it is written in PHP. Currently, there are 161 comments on Hacker News with the words "Nextcloud" and "slow" in them: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Nextcloud%20slow&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... The same applies to Gitlab, which is written in Ruby and runs on Ruby on Rails under the hood. Currently, there are 1,656 comments on Hacker News with the words "Gitlab" and "slow" in them: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&query=Gitlab%20slow&sort=byPopularity&type=comment https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que... Had they made the right technological choices from beginning, there would be no need for articles such as "Why We’re Sticking with Ruby on Rails at GitLab" in 2022: https://news.ycombinator.com/item?id=31684529 https://news.ycombinator.com/item?id=31684529 With the CEO of the Gitlab admitting in the comments: > Performance is indeed worse. We're moving the 20% of the app consuming 80% of the compute to Go.
- ipaddr 4y ago
  You should. I wouldn't consider a project not in php and applicant tracking is important.