When someone is empowered to work remotely, and is salaried and not held to specific hours, then it's very hard to identify what work is "theirs" and what work is "the company's" in a legally consistent way. Yes, it's usually obvious from context, but context doesn't always carry to a court of law. It can be particularly messy because the kinds of open source projects one contributes to often overlap with the work they do in their day job.
So most companies which are salaried and allow WFH will usually ask employees to explicitly list any project they work on which they don't want owned by the company, with the expectation being that everything unlisted is owned by the company. It's a bit cumbersome, but generally the least bad option.
At our company we have a form to file if we do work outside of hours on OSS or pet projects, and to the best of my knowledge nobody has ever had their application denied.
edit: it's important because it's symmetric - not only does this define what _isn't_ property of the company, it defines what _is_. So if you come up with a clever solution to a problem for a company purpose and introduce it into an OSS project, it doesn't come back to haunt the company.
> 1. my "fear" would be that if I use the same Postgres for the queue and for my business database...
This is a feature, not a bug. In this way you can pair the handling of the message with the business data changes which result in the same transaction. This isn't quite "exactly-once" handling, but it's really really close!
> 2. also that since it would write messages in the queue and then delete them, there would be a lot of GC/Vacuuming
Generally it's best practice in this case to never delete messages from a SQL "queue", but toggle them in-place to consumed and periodically archive to a long-term storage table. This provides in-context historical data which can be super helpful when you need to write a script to undo or mitigate bad code which resulted in data corruption.
Alternatively when you need to roll back to a previous state, often this gives you a "poor woman's undo", by restoring a time-stamped backup, copying over messages which arrived since the restoration point, then letting the engine run forwards processing those messages. (This is a simplification of course, not always directly possible, but data recovery is often a matter of mitigations and least-bad choices.)
Basically, saving all your messages provides both efficiency and data recovery optionality.
> 3...
Legit concern, particularly if you're trying to design your service abstraction to match an eventual evolution of data platform.
> 4. don't provide "fanout" for multiple things
What they do provide is running multiple handling of a queue, wherein you might have n handlers (each with its own "handled_at" timestamp column in the DB), and different handles run at different priorities. This doesn't allow for workflows (ie a cleanup step) but does allow different processes to run on the same queue with different privileges or priorities. So the slow process (archive?) could run opportunistically or in batches, where time-sensitive issues (alerts, outlier detection, etc) can always run instantly. Or archiving can be done by a process which lacks access to any user data to algorithmically enforce PCI boundaries. Etc.
I’m constantly amazed at how differently I learned to do things from my father than from school.
My father had all sorts of approaches similar to this, and it’s how I learned to write essays (outside-in) and research (inside-out), and which I later applied to programming. It made school trivial and fun, and it’s what I’m teaching my kids.
The value people produce is an asset. After all, you don't own people, you buy their effort.
A contract can be an asset. Usually the unrealized future value of the agreement has value should you need to make a deemed disposition (or have some other valuation event). It gets very obviously complicated and fuzzy though, which is where accountants make the big bucks. It's pretty rare that a company chooses to make a contract valuable, but it often comes up in bankruptcy proceedings.
As an example of contracts having value, a few years ago I was involved in the acquisition of some media distribution assets, and one such asset was a transferable "MFN" contract with a major publisher. That was a very, very valuable asset.
When someone is empowered to work remotely, and is salaried and not held to specific hours, then it's very hard to identify what work is "theirs" and what work is "the company's" in a legally consistent way. Yes, it's usually obvious from context, but context doesn't always carry to a court of law. It can be particularly messy because the kinds of open source projects one contributes to often overlap with the work they do in their day job.
So most companies which are salaried and allow WFH will usually ask employees to explicitly list any project they work on which they don't want owned by the company, with the expectation being that everything unlisted is owned by the company. It's a bit cumbersome, but generally the least bad option.
At our company we have a form to file if we do work outside of hours on OSS or pet projects, and to the best of my knowledge nobody has ever had their application denied.
edit: it's important because it's symmetric - not only does this define what _isn't_ property of the company, it defines what _is_. So if you come up with a clever solution to a problem for a company purpose and introduce it into an OSS project, it doesn't come back to haunt the company.