I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job.
Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that?
It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with.
Simply put, there are too many modes of failure at the individual level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here.
I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.
I personally think _most_ people should treat their jobs as a _day_ job - unless they have actual ownership in the company (beyond what would be a 50-100k payout at option time)
I think this is key when people talk about "ownership". Actually owning a product means that if it fails you're holding the bag, if it succeeds you take the profits. And you have full control over it. Unless a company actually wants to do this I wish they wouldn't use that english word.
Trying to hire an employee and tell this story that they "own" the product is just silly. It's like companies that try to describe themselves as a family - just kind of a weird and incorrect use of a real word that has other meaning.
I certainly did a ton of traveling/speaking/meeting with customers/sometimes late night calls in different time zones/etc. but I still treated it as colloquially a "day job," albeit not really a 9-5 one.
In my experience this is mostly big-company vs. small company cultural differences due almost strictly to size and scaling. Small companies work best when individuals have ownership and large companies with team based ownership. They attract culturally like-minded people.
The highest-agency, highest-ownership team I worked on was at Target of all places. (To be fair, it was not a typical team for the company!) The VP who made that work learned that style of leadership from a decade in Strats at Goldman. Both are pretty big as companies go!
On the flip side, I've seen early-stage startups and scale-ups where engineers did not have real ownership. It's easy to get into a situation where an individual engineer "owns" a specific part of a startup... but can't make any real decisions on it because the founders want to dictate work at a week-to-week level or something.
I think the cultures naturally change with scale. Is isn't a requirement, just a tendency. At least from my personal experiences, friends and read over the years this seems like a good general heuristic. I personally use it as a primary rule for job seeking, I ignore any company over ~500 people. Once they are bigger than that and their culture seems to start naturally evolving to the same stance of people being interchangeable cogs that have no worth as an individual. This naturally leads to team ownership as there is no one else.
You're kind of right. But at the same time they are nowhere close. The beauty of Linux containerization is that processes can be wholly ignorant that they are not in fact running as root. The containers get, what appear to them, to be the whole OS to themselves.
You don't get that in macOS. It's more of a jail than a sandbox. For example, as an app you can't, as far as I know, shell out and install homebrew and then invoke homebrew and install, say, postgres, and run it, all without affecting the user's environment. I think that's what people mean when they say macOS lacks native containers.
I find this whole document hard to read. A "diff" colloquially refers to the difference between two things -- files, directory trees, whatever. What TFA refers to as a diff has been always known as a patch, at least to me.
This is nothing about diffs, but entirely about patch metadata management. I mean, sure, noble goal, but this is just shuffling bits around. If they proposed that metadata was required to be JSON that would be one thing, but instead it's some weird self-describing length-delimited nonsense that just disguises the same problems that exist today. It's already extensible! Just type words!
I've spent a lot of time parsing things out of git commits and patch files and while some standardization would be neat, this isn't it.
That said I find the argument that git diff style is more or less canonical more compelling than I have in the past. So there's that.
> A single diff can't represent a list of commits
A patch set can! Why on earth would you want that represented by a single diff is beyond me.
It is in fact totally clear. There is a LICENSE file in the root of the repository. Adding a new subtree (directory) should not call into question whether or not that tree is covered by the preexisting license. That's silly. If they wanted to change the license then there needs to be an actual change to the license.
Sorry to harp on this point that isn't fun performance engineering, but I think the tricky bit comes in exactly where you draw the line.
Is offering Postgres-as-a-service with PgDog under the hood okay?
What about a document-oriented, Firebase-equivalent that has PgDog and Postgres under the hood?
What about a low-code application development platform?
What about all of the above, but internal-facing vs paying-customer facing? Does it matter if the internal-facing is paid for via a cross-charge rate (e.g. a multinational company that charges divisions in other countries for services)?
Does a customer of all of the above services have to AGPL their code and release it publically?
Maybe it's all obvious, but that is the sort of thing I worry about with AGPL commercially. Even though I love OSS.
Everything is fine. You never have to release your code for anything that's not PgDog itself. If you're running PgDog as a service, anyone who connects to it can ask you for the source code of PgDog. That's what AGPL says.
In practice, if you use it internally, your teammates already have access to the code. Requirement fulfilled.
Your databases run on a private net typically, so your customers can't connect to PgDog directly: AGPL doesn't apply. That's internal use.
If you're running a DB cloud and using PgDog as a proxy, anyone who connects to it, i.e. your customers can ask for the code to PgDog. If you didn't modify it, just point them to my repo. Requirement fulfilled.
If you did modify it, e.g. added some cool feature or fixed a bug, you'll have to show your clients what you did. That's real open source. That's how GPL was supposed to work. Code is free, and so is knowledge and our ability as humans (and now machines, lol!) to learn from it. GPL stopped working because we stopped shipping software on CDs. AGPL is it's modern version.
I love open source and that's why I'm using AGPL. GPL and FSF is the reason why I can do what I do today: I learned from open code written by thousands of brilliant people who chose to share that with the world. Now it's my turn to give back.
I'm trying to read the AGPL in the most tricky possible light to see where the exact boundary is.
From what I think you're saying, I could make a service that uses PgDog behind the scenes, which would mean I could modify PgDog without releasing the source code.
However, given most people making PgDog As A Service wouldn't put PgDog directly on the internet, but would put it behind something like HAProxy, or perhaps even a REST API that takes in a SQL query as text and runs it on PgDog. Would either of those options then mean they could modify PgDog without releasing the modification's source code?
That's a good question. To echo the comment above/below, we would have to define what a "direct connection" is.
In my interpretation (and as the founder, I think that matters because I would be the only one who would have any enforcement interest) that means TCP. AGPL says "over network" and that means TCP/UDP. To me at least.
So if you're running a SaaS, the TCP connection is broken by the app layer and all the business logic in between. Your code and proprietary products are safe.
And just to restate my previous point: PgDog is a company. If you want to use the product, we'll make it work.
I mean no disrespect, but it doesn't say that. This is your interpretation. There is insufficient legal precedent to validate this interpretation, and thus there is inherent risk.
The risk specifically is that if I use PgDog as a component of a larger application (e.g. a SaaS app) then the entire application may be in scope.
You can fill this webpage with text stating otherwise but it doesn't matter in the slightest. If your intent is that only users connecting directly to PgDog are entitled to receive the source, then I encourage you to develop a license saying as such. But that's certainly not the AGPL, unfortunately.
(Caveats being I'm not a lawyer, and this is not legal advice. I certainly don't enjoy imagining how one would even define direct connections in a court of law.)
FWIW your heart is in the right place. I wish the world worked the way you describe.
> Unfortunately this advice is incompatible with that of most legal departments.
I see this comment pop up every now and then on HN in specific, but I've never personally had a lawyer tell me this; is there any chance anyone could share an actual example of this?
1TB memory servers weren't THAT exotic even in say 2014~2018 era either, I know as I had a few at work.
Not cheap, but these were at companies with 100s of SWEs / billions in revenue / would eventually have multi-million dollar cloud bills for what little they migrated there.
The TL;DR is that Amazon S3 now supports "conditional writes" which are guaranteed to fail if the file was written by some other writer. This is implemented by sending the ETag of an object's expected version alongside the write request.
Litestream now depends on this functionality to handle multiple writers. Think of optimistic locking.
What made these games different was that the musical themes were significant and well known long before you installed your SoundBlaster. The music was mixed at high intensity out of the box allowing it to influence you, each track tailored to the moment.
This gave the series a leg up in that the music could actually communicate information effectively -- a tense moment, the shifting tide of the battle, the calm after a victory -- whereas other games simply had to put up waveforms that sounded pleasing.
To be fair many games experimented with sound design in this era, but few had such legendary IP to build with. An unfair advantage to say the least. The folks wielding iMUSE clearly knew what they had.
Yocto is significantly better than what proceeded it. I could fill a book on ways it has pushed the envelope for embedded development.
Is Yocto a steaming pile? Yes absolutely. But it remains a means to an end.
I'd struggle to accomplish with Nix what can be accomplished out of the box with Yocto. Now that being said I'd certainly try and use Nix over Yocto any day of the week.
I remain optimistic and that the two will converge and it will more or less not matter, though I'd much prefer Nix to consume embedded development than Yocto become Nix-pilled.
Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that?
It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with.
Simply put, there are too many modes of failure at the individual level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here.
I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.