* DONE Why I don't want to use existing CRM and ERP systems :tech:blog:
CLOSED: [2022-09-21 Wed 13:42]
:PROPERTIES:
:CREATED:  [2022-08-31 Wed]
:MODIFIED: [2022-08-31 Wed]
:ID:       erp-crm
:END:
:LOGBOOK:
- State "DONE"       from "DRAFT"      [2022-09-21 Wed 13:42]
- State "DRAFT"      from              [2022-09-04 Sun 21:44]
:END:
There are quite a few such open systems around,
be it CiviCRM, SuiteCRM or ERPNext,
but unfortunately they all fail on a crucial aspect for me:
By using them,
you essentially lock yourself into a chunk of software,
an ecosystem that you can't easily leave.
Because lock-in effects not only occur because of proprietary formats,
but also workflows, configuration and non-transferable data.
# TODO LINK VENDOR-LOCKIN

Since these systems usually cover lots of different functions,
they will form the core around which your infrastructure evolves -
you can add extensions, work with their API, connect everything to it.
But what if you become dissatisfied with the core?
If it becomes abandoned, proves clunky, does not scale with you?
If you exchange the core,
you have to change everything,
which means a lot of work.
You are locked in!

This becomes even worse if the application development has an open core model,
wherein some extensions are offered at a cost.
Because chances are that the main location for extensions is controlled
by the same commercial entity,
which might prevent free alternative extensions from being offered officially*.

This is why I want to build our suite from independent applications
that do one thing and do it well,
connected through open standard data formats.
This way, the lock-in and thus the switching costs
are always bounded to the application
that proves unfitting,
so you can exchange any part of your suite
and preserve the whole,
keeping it up-to-date and flexible.
This way, there could indeed be one framework serving essentially all needs,
because whenever there is a deviation,
an application is simply exchanged,
keeping the whole intact.
** Nextcloud
This is why I am still wary about using Nextcloud:
It is kinda battle-tested,
but as we start to depend on it we realize that many features
are not fleshed out as well as in commercial alternatives,
leading me to wonder
whether we could do better by connecting separate applications
that do each of its functions well.

Yet one thing that still pleases me is the external applications plugin:
That way we have turned Nextcloud into a tabbed hub of independent applications
which are seamlessly embedded and switched between,
yet stay usable without Nextcloud.

** Time-Tracking
Another good example is time-tracking:
The ticketing system Zammad has meager time-tracking,
issue trackers and task managers
(which should really be combined,
why do version control platforms even do issue tracking themselves?)
sometimes offer it.
But none of these platforms does it well,
because it is not and should not be their primary concern.

A good time-tracker needs to do only few things,
but these so well that it quickly becomes second nature.
It needs to track different contexts and tasks in detail,
ideally pulled in from other applications
and automated through various triggers,
natively on any platform including offline and on the command-line,
so it can be further integrated into other workflows.
So we need a protocol and an efficient platform to handle only this,
which then hands over the data
to project planning, billing & co
as well as reporting tools
(which also don't need to be part of the actual tracking platform).

Yet most time-tracking applications become some kind of monstrosity,
growing vertically to do project management and billing as well,
typically faring miserably or doing pretty well
until they don't meet the needs anymore and you are again locked in,
forced to mess with an old codebase
or throw everything out for something else,
incuring high switching costs.
Often they also offer fancy reports,
but these are again unnecessarily tied to the platform.

** Footnotes
*Don't get me wrong,
I am not against offering software commercially,
but I am a big proponent of open-sourcing all components
including their connections and build pipelines,
and charging for the service -
custom developments (which will then be open-source, too),
hosting and training.
Because only if everything is available
can I trust that there is no gatekeeping when it comes to code,
yet most people will prefer the paid, serviced variant,
which is totally okay!
Everybody Wins!