71–80 of 85 posts
And even if you are at a company that realistically won’t be acquired, you should always be prepared to look for a job at a moment’s notice.
I’m a general python contractor. So far all of my clients have been acquired or had layoffs within a year of hiring me.
This might be UK specific because of how UK labour laws work.
At a company I worked at the CEO out of the blue called for an all hands, all offices meeting with a few days notice. Everybody who wasn't in the main office had to connect via video link. This had as far as anyone could remember never happened before. There was no agenda and no hints as to what the meeting was about. Even senior managers knew nothing. So obviously rumours started flying, people get nervous, and ever…
At a company I worked at the CEO out of the blue called for an all hands, all offices meeting with a few days notice. Everybody who wasn't in the main office had to connect via video link. This had as far as anyone could remember never happened before. There was no agenda and no hints as to what the meeting was about. Even senior managers knew nothing. So obviously rumours started flying, people get nervous, and ever…
and it probably cost $17m in consultants
Relevant: https://reclaim.ai/blog/this-meeting-could-have-been-an-emai...
These all seem accurate and I'd add even moreso than security (which can be prioritized for other reasons) a focus on buttoning up open source licensing / IP ownership is a dead giveaway that a sale is close. Also the hiring and retention thing is probably less about distraction and more about not taking on additional expenses in the middle of due diligence - generally the acquirer will want to have more of a say in…
Earlier quoted context omitted.
That security point stood out to me as well. First of all, who intentionally writes code to contain SQL injection vulnerabilities anno 2024? Or knows about it and doesn't fix it? Is it really that weird that someone fixes it?
Sometimes there's clearly no risk but an automated tool flags it anyway? Requiring a creative and meaningless "fix".
That said, we now have some customers who have extremely stringent security requirements, and for understandable reasons. They want every CVE resolved for every release; this is going to cause a notable amount of work to 'resolve' issues which aren't issues by taking developer time to update and test third-party libraries, or even patch the libraries ourselves if the upstream CVE hasn't been resolved yet.
It's unquestionably worth doing if this is a dealbreaker for our customers, but could definitely impact things in the short term by requiring fixes which are technically unnecessary.
- A lack of guiding objectives and growth plans (which are vital in this particular industry)
- Major personnel change on the executive team. New exec had lead CIC events at several prior orgs.
- Complete re-organization of the development side of the business, with a focus on cost cutting and separation into separate divisions.
- Entirely new HR dept hired. More red tape and internal scrutiny.
- Increased political power consolidation within legal department, with several odd (politically motivated?) high level promotions there.
- Lack of internal promotion and compensation. Not replacing personnel who left because of this environment.
Any one of these wouldn’t be a red flag by itself, but all combined were a fairly clear indication.
At a company I worked at the CEO out of the blue called for an all hands, all offices meeting with a few days notice. Everybody who wasn't in the main office had to connect via video link. This had as far as anyone could remember never happened before. There was no agenda and no hints as to what the meeting was about. Even senior managers knew nothing. So obviously rumours started flying, people get nervous, and ever…
Earlier quoted context omitted.
If the license says I must make the source code available, don’t I also have to have some mechanism to provide that code if asked?
Debian based distros (and all the others) have a command to run and get the sources for ALL open source packages installed on the system. So, there is nothing to do there. apt get source package. If someone asks for source code for a library, simple point them to the GitHub repository. This isn’t rocket science and it isn’t worth automating because practically nobody asks for it.
For GPL-licensed code, you should provide the sources yourself. "Point them to a GitHub repository" is not acceptable, since the repo might disappear or change contents without you noticing.
And it is definitely worth automating, if you are releasing at scale (either many products or many versions). Otherwise you will be left having to handle requests like "does anyone remember the exact contents of our product X, of version of 2023-03-03?"