Show HN: Bigcapital - A open-source alternative to QuickBooks | Hacker News Reader

Show HN: Bigcapital - A open-source alternative to QuickBooks

github.com

93 pointsabouolia32 comments

Previous threads (all created by the same OP):

* May 29, 2023: https://news.ycombinator.com/item?id=36114095

* May 29, 2023 (2): https://news.ycombinator.com/item?id=36118990

* July 2, 2023: https://news.ycombinator.com/item?id=36566556

Yes, since https://news.ycombinator.com/item?id=36118990 in particular got significant attention (200+ comments and 17 hours on the front page), this repost counts as a dupe.

It may be in there somewhere but I don't see a mechanism for talking to banks using standard protocols to at least retrieve bank transactions. Without that, an accounting system is an unusable toy.

I’ve seen some tools with plaid integration. Idk how plaid cornered the market but it seems to be the only option available for oauth with banks.

There is also yodlee

https://www.yodlee.com/open-banking

We have been using wave apps for the last couple of years. Do you have a comparison page?

Wave looks really nice, though it’s a shame they only support US tax. For Australians the accounting package has to support “STP2” which is the governments API for reporting payroll and super, otherwise it’s borderline illegal to use.

We desperately need an alternative to qb

I tried to evaluate Bigcapital but it's kind of a mess to deploy via self hosting. The docker-compose setup is really hard to break apart, the stack is bizarre (mongo, multiple myql databases, and redis), and the way you do upgrades and migrations left me feeling very uneasy. Additionally, my accountant wouldn't use anything this thing exports from what I can tell. For now I'm sticking with GnuCash, but I have my eye on some open source ERP systems--they're extremely complex though, with every screen being customizable. All I want are HR and finance functions in one place without having a dozen Google Docs and Sheets floating around. I couldn't care less about the level of customization most ERPs provide.

Anecdotally, we've seen a number of larger "open-source alternative to X" projects posted on HN of late that are technically self-deployable, but require so much up-front knowledge that it's not actually accessible to those who might truly be liberated by such software.

I mean no slander or disrespect to anyone involved, but there was a DataDog alternative posted sometime in the last few weeks that had a docker-compose with like 15 containers in it. Required running a few different Typescript servers, a Clickhouse instance, Redis, MySQL, the lot of it. I'm sure it was a fully-featured service that made adequate use of those resources, but it also reminded me of why people pay out the wazoo for DataDog: nobody wants to manage all that stuff!

EDIT: the repo linked in the GP contains 3 instances of what you could call databases: MariaDB, Mongo, and Redis. There doesn't appear to be any explanation in the deployment docs for why all three are necessary.

> I mean no slander or disrespect to anyone involved, but there was a DataDog alternative posted sometime in the last few weeks that had a docker-compose with like 15 containers in it.

Reminds me of Sentry: https://develop.sentry.dev/self-hosted/

This is their example docker-compose for self-hosting: https://github.com/getsentry/self-hosted/blob/master/docker-...

It has:

  - exim4 (smtp)
  - memcached
  - Redis
  - PostgreSQL
  - Zookeeper
  - Kafka
  - Clickhouse
  - geoipupdate
  - 18 containers for something called snuba (integrates with Clickhouse?)
  - 2 symbolicator containers
  - web app
  - cron
  - 18 other utility containers
  - Nginx
  - relay
  - 2 vroom containers

Meanwhile, as far as the other options in the APM space go, this is how Apache Skywalking looks like:

  - web app
  - back end API
  - database (Elasticsearch/OpenSearch, PostgreSQL, MariaDB/MySQL or something else)

I'm glad that generally it's good enough for my needs, because I can't imagine actually having to self-host Sentry. Then again, something like Graylog does log shipping better and without a doubt Sentry has lots of nice features... as long as you don't have to run it yourself, because many people out there won't realistically be able to do so.

> EDIT: the repo linked in the GP contains 3 instances of what you could call databases: MariaDB, Mongo, and Redis.

That's not too bad, though, but seems like an interesting choice (both a regular RDBMS and a NoSQL one; Redis would probably be useful for caching etc. for either).

Sentry is definitely a bit heavyweight on the services. Though, it makes sense since you’re effectively running everything they run for their saas business built for a whole other scale.

The trade off is that it’s far more complex than what anybody needs if they just want to run sentry locally. It used to be a lot simpler but now it’s pretty much impossible to even understand how they store data without spending a long time studying it.

To be fair to them though, their migrations and releases have generally been solid and reliable.

What are you talking about?

Running Sentry isn't hard despite crazy number of containers as long as you do it their way and use their docker-compose.yml.

The problem is running it on 4GB instance with 4GB swap is bare minimum which costs quite a bit to give it a dedicated instance.

But you can't beat its features. We should be glad it's provided for free and self hosted version isn't limited. Can't live without it.

You know what skywalking doesn't have though, apparently, is Ruby support!

I would love to understand a bit better why this one gets left off the list so often. "There's just nobody interested in putting those two things together" I guess, it's surprising to me though, because Ruby is pretty popular AFAIK.

> Anecdotally, we've seen a number of larger "open-source alternative to X" projects posted on HN of late that are technically self-deployable, but require so much up-front knowledge that it's not actually accessible to those who might truly be liberated by such software.

Any self-hosted application really needs someone technical unless you're providing something like the DigitalOcean deploy button.

Docker-compose requires technical knowledge to run locally. Sure running "docker compose" is easy but installing it often isn't. As someone quite technical I'm honestly not sure how that would work for deploying on to AWS or GCP even though I know it's possible. I would have to look into it.

Ansible scripts require technical knowledge. Again running the command is easy but installing ansible isn't.

How DigitalOcean's deploy button is really easy as is shown in my demo video - https://www.youtube.com/watch?v=cbInyGtqLCs&t=1s. Note there is 10 minutes of my app demo inbetween starting the process and me using a deployed version. You can even try it out at https://github.com/BillaBear/billabear it's literally super easy. It's also silly easy to actually build. "DigitalOcean's app platform is so good it makes BillaBear looks good since the deployment is so easy" is literally what I've said to people.

> I mean no slander or disrespect to anyone involved, but there was a DataDog alternative posted sometime in the last few weeks that had a docker-compose with like 15 containers in it.

If this was us [1] (an OSS Datadog alternative posted last week :D ), we do have quite a bit (11, 2 are optional) but we're working on bringing it down.

We currently split our ingestion pipeline into 3 independently scalable bits, but we can probably bring it down into 1 for any small-scale deployment. Otherwise we do have the standard need for a cache (redis), db (mongo), main storage (clickhouse), and then the standard API server + frontend, and a separate task to run alerts.

There's likely a few more things we can merge together, but it comes at the expense of making it unscalable to workloads typical to a company and divergence in the code base, which overall doesn't seem like the right tradeoff.

Imo the real concern as someone that personally owns too many tiny VM instances is resource footprint - which can be tuned down to ~1GB of memory for us (depending on server load).

Feel free to open an issue too if you think there's something we can adjust there as well.

[1] https://github.com/hyperdxio/hyperdx

Totally agree, nobody can manage that amount of containers, it doesn't mean if it was self-hosted would excuse the deployment is not necessary to be easy, always the deployment of self-hosted should be easy with sample CLIs. and also providing pre-configured instances on the most popular cloud services like on DigitalOcean to deploy the app with sample clicks (instead of CLIs) that would great additional for non-techincal people and that's what we're seeking for, in terms of 3 instance actually we used Mongo for Agenda.js but we want to get rid of it ASAP.

When I come across this scenario, I often ponder whether it's part of the business strategy for those who offer open-source software for free alongside a paid hosted version. There seems to be a conflict of interest at play here: the more user-friendly the software becomes in terms of installation and operation, the less appealing the hosted version appears.

I'm currently working on an open-source software project with a hosted version of my own (https://sql.ophir.dev). It's a website builder, and my aim is to turn the ease of deployment and operation into a competitive advantage, which is prominently highlighted on the homepage. However, I recognize that it might be overly idealistic to expect the same from others. My target audience mainly consists of individuals who will need to manage the software themselves. In contrast, in many other domains, the decision-makers selecting the software and the individuals responsible for its operation are not one and the same.

Even if it isn't as cynical as doing it on purpose, you can still end up with this scenario because the company is simply not ever going to prioritize making the self hosting option easy.

The deployment is really easy to do and well documented with some FAQs you may face, yes there were some issues in setup before couple of months ago but we fixed them even the database migration now is automated. that is acceptable especially when you use a new technology. you can join to our Discord and the team will help you to deploy it on your machine.

> that is acceptable especially when you use a new technology

Not really when it's accounting software.

>The deployment is really easy to do

I mean, fwiw here's what we do to deploy QuickBooks: double click on image or CD, drag/double click icon, follow any prompts, now it's done. Click on icon in dock to launch QB thereafter. There was no need to read any FAQS, join a Discord or even send an email. That would be my definition of "easy". I suppose "here is a VM image ready to go, download and click button/run command" wouldn't be terrible though still already a massive leap in needs over QuickBooks.

>that is acceptable especially when you use a new technology

QuickBooks had its first release 31 years ago. Like others say I'm sure there are reasons for the explosion in nested stacks upon stacks of complexity, but I'll admit I still find myself pretty befuddled about how we ended up here. I guess it looks like from the docs the goal is exclusively compete with the QB Cloud Service specifically so that takes a bigger stack, like you're building for B2B. But kind of feels like it's an odd choice of targeting here. QB was always aimed heavily at small, and eventually medium-small businesses. Huge places used other stuff. Small end of the scale are also the ones who face the most pain from the shift to subscription-only if you didn't snag a last physical copy. The docs say

>Bigcapital is built with a multi-tenancy architecture that allows multiple organizations to use the same software while keeping their data separate from each other

Is this actually something in demand here? Why wouldn't each one run their own, or if not just pay Intuit? Is the idea that various companies will offer Bigcapital services for sale? And it says "keeping data separate" but I don't see anything about E2EE in the docs or FAQ, though maybe it's buried somewhere. If the data is only separate based on user permissions what orgs are going to trust something as sensitive as business financial data to a multi-tenant situation for something unproven? I don't find it promising that the (incredibly sparse) docs have this to say about signups:

>The environment variable SIGNUP_DISABLED should be set to true to disable the signing up of new users. When set, the following facts hold:

So, does that imply that by default it's just open to the world and anyone can sign up? In 2023?

I guess I'll watch the project if only because subscription-only for QB sucks and I'm sure will be a problem eventually, but... I dunno. This isn't what I would have immediately thought of for "An open-source alternative to QuickBooks" in terms of approach.

I would recommend trying to book 2 hours of an accountant's time (not a software dev) and seeing if they are able to install this during that time window. I suspect they would not be able to.

I second this to how difficult it is to deploy the app.

My feature request is to be able to deploy sth like this on heroku or other paas and to string all of the dependencies with env variables.

What's the most important features in an accounting system in your opinion?

Are they of a kind, or are there some killer features on expensive commercial tools that the free fare can't match?

The biggest barrier to adoption that all new entrants to this market must overcome is finding finance and accounting professionals willing to use their product. The second is finding banks, auditors, and investors willing to use statements from an accounting package they've never heard of.

Thanks. What do you mean by "finding banks, auditors, and investors willing to use statements from an accounting package they've never heard of." ?

Is that a file compatibility issue. Are there not standard file formats for exchange of data in the financial industry?

Don't people, as a last resort maybe, just send a csv, or print the ledgers out on paper?

There are a few different standards. The problem with the generic csv is that headers still need to be specified. Otherwise, the person doing the importing has to specify/confirm what each column means.

The standard file format is "Quick books backup".

A big problem is the differences between each countries needs. Securely connecting to your banking and payroll and also the difference needs between different countries tax systems. Europe needs lots of currencies and vat tracking vs USA needs doesn’t usually want all that.

I would say that many businesses just want a desktop based system and web based has security and maintenance requirements they just aren’t interested in.

Payroll.

I ran a business successfully for many years with GnuCash. I only switched because I wanted to offload bookkeeping to a professional for a couple hundred bucks a month, and she was only familiar with QuickBooks.

Reply on news.ycombinator.com