Was always wanting to do something like this before they swapped ours out for a SaaS+hardware butterfly mx thing.
Those Doorkings have had to get replaced at so many buildings in Seattle now that criminals figured out how easy they were to override.
1,621 karma · joined June 28, 2012
Those Doorkings have had to get replaced at so many buildings in Seattle now that criminals figured out how easy they were to override.
Having the source on GitHub feels like a nice way for some people to peek through it... but there's clear compromise between archival and sharing some source.
As far as games, and the broader collection of earlier closed source applications: it's incredibly difficult to clear rights if there's third-party intellectual property that was written without the intention of being open, or licensed content, etc. It also takes a bit of an army to clean/review code and comments to get them ready.
[Source: I run our open source office... we help advise internally, but aren't staffed to do nostalgia open sourcing and so need to partner with people and teams who can help]
While the article claims there is no money to be made in EV charging to incentivize and align with building owners, there's plenty of similar "amenities" that easily can help differentiate a "luxury" apartment building, hopefully they become more common.
I've also estimated my cost to commute to my tech job in the suburbs (thankfully full-time remote now), and it was staggering how much that was including insurance, maintenance, tolls, electricity, etc., compared to free options/transit/corporate bus/remote work/my daily mortgage cost.
Today, I look at the math, on a cost-per-day or cost-per-use angle, and I'm so happy that I went for something nice that I enjoy.
I do feel like cost-per-day amortized is probably more interesting for a lot of decision making.
We probably over-estimate how often we'll use a product or service.
Don't get me started on my new Model Y that doesn't have the game controller-only games... or my Model S that doesn't let me actually play games in the back. Wait, it's a car, I'll be fine.
The ordering, waiting, and delivery process really do require us all to connect - if only for mutual support through frustration -
There is an aspect of "who cares" when I hear about slightly different door panels, or heated windshield wipers, or a manufacturing improvement for newer cars being built.
Yet it's easy to get lost in the "OMG THE NEW HEADLIGHTS MY CAR IS RUBBISH" world, too.
Enjoy any EV, when you're ready, it'll be a great car for many years.
Our process revolves more about _using_ open source than forking specifically.
Whenever a build runs at the company, we have a detection task that identifies the open source that is used, storing an inventory. We evaluate the open source licenses for that inventory, and have automation depending on the license that will help inform a team that has taken a new dependency with specific legal obligations - could be to get business and legal approval for something, to take training and learn about copyleft software and licensing, or that they need to post third-party buildable source. We're also able to use that inventory to help with incident response and blast radius analysis.
To scale, we need to make sure that our guidance and policies are in front of people, but we know that engineers want to get work done (or will find a way around what we have in place), and so need to be efficient and straightforward.
Not all situations will require a business or legal approval. Our motto has been "eliminate, automate, delegate" - eliminate onerous bureaucracy and policies - automate licensing compliance and inventory and approvals - and delegate to business leaders and others when there's a need for humans to be involved.
Sorry for the long answer.
My guess is that they were going through a checklist of what to do when releasing open source changes, and didn't understand what they were doing.
A lot of why we've had to put some guardrails in our system has been to point people to guidance and training on open source.
I've sent the team that works on this repository an e-mail, but I don't expect to get a response on the holiday.
We have merged a pull request that restored the correct LICENSE file and copyright, and are in touch with the upstream author Leśny Rumcajs who emailed us this morning. We'll look to revert the entire commit that our bot made, too, since it updated the README with a boilerplate getting started guide.
The bug was caused by a bot that was designed to commit template files in new repositories. It's code that I wrote to try to prevent other problems we have had with releasing projects in the past. It's not supposed to run on forks.
I'm going to make sure that we sit down and audit all of our forked repositories and revert similar changes to any other projects.
We have a lot of process around forking, and have had to put controls in place to make sure that people are aware of that guidance. Starting a few years ago, we even "lock" forks to enforce our process. We prefer that people fork projects into their individual GitHub accounts, instead of our organization, to encourage that they participate with the upstream project. In this situation, a team got approval to fork the repository, but hasn't yet gotten started.
To be as open as I can, I'd like to point to the bug:
- The templates we apply on new repositories live at https://github.com/microsoft/repo-templates
- The bug seems to be at this line of the new repository workflow: https://github.com/microsoft/opensource-management-portal/bl...
- The system we have in place even tries to educate our engineers with this log message (https://github.com/microsoft/opensource-management-portal/bl...): "this.log.push({ message: `Repository ${subMessage}, template files will not be committed. Please check the LICENSE and other files to understand existing obligations.` });"
In hindsight... only a few ever moved back to Michigan, and wow, yeah, what a recruiting pipeline, and what brain drain.
I imagine that only accelerated the last decade as midwest total compensation likely trailed significantly.
For a while, it felt like the tech firms were strip-mining all the talented midwest engineers who were willing to relocate. I hope the more remote-friendly future helps people keep their local roots.