Related to "Hire open source hackers", I'd like to work for a company that respects, and dare I say encourages, open source contributions.
I recently went through the approval process to contribute to a project on my own time. Due to its nature, the project obviously would not conflict with my business unit or any business unit within the company. Approval should have been a 5 minute conversation with my manager.
Instead, I had to write up a proposal for the open source review board. After a week or so, they agreed it was acceptable. The next step was to fill out a form and get a VP to manually sign it. This took a bit of time since the VP is 4 levels up and was, unsurprisingly, out of the country.
I would take that further: I want to work for a company where you need a form from the VP to allow any work in the company to go un-open-sourced. Everything is MIT-licensed and posted to Github by default. Only the secret-est of secret sauce gets redacted.
If I had to guess, it might be because, while philosophically more "pure", I believe GPL is a less pragmatic license if the goal is getting your software more widely used.
I'm the VP of Software Development at my company, and as long as what we open source isn't advantageous specifically to competitors or required significant resources to produce, it's all gravy.
So far, nothing has been vetoed. We use tons of NodeJS and PHP frameworks/libraries, so contributing and open-sourcing is part of why we enjoy our job so much :)
Instead, you'd just let an engineer grab some AGPL code and use it in your web stack without considering the implications? I've seen it happen, and the engineer in question didn't understand why — or even that — it was a problem.
Sure, it's a little process-y, but it's not there just to check boxes on forms.
"I recently went through the approval process to contribute to a project on my own time."
Which I took to mean he needed formal approval to contribute to some external open source project on his own time, completely outside of work and unrelated to his work project. Which is pretty bonkers.
Of course if you're pulling open source in to your projects it is wise to have that reviewed first, though I have to admit that at my current job I'm slightly annoyed at the formality of things like having to apply to get Apache 2.0 licensed code brought into our Android project when the Android SDK itself is under exactly the same license as the OSS project. However, I also understand that I have a far better understanding of the implications of various open source licenses than Joe Average programmer guy, so I "get it".
He's not talking about using open source code, he's talking about contributing to open source in his own time.
I have a gut feeling I know which company he's talking about, because I used to work for them too. All contributions to open source, even off company time, must pass through the approval bureaucracy.
The worst part about it is that said bureaucracy is staffed with people permanently afraid that they will sign off on something that might at some unforeseeable point in the future come back to compete with the company, and their neck would be on the line for it.
The result being that they're incredibly risk-averse and not inclined to approve anything, even if it has zero relationship with what the company does. In other words, open source contributions are de facto banned throughout the company, but the company gets to make a lot of noise about how they're open to the idea.
I have one colleague who quit his job because of it, one of the best coders I've ever met. No surprise that the company overall has an attrition rate easily in the 20-25% per annum range.
I work for that company as well, and had I known their open source contribution policy was so draconian (and their general attitude toward open source so utterly mercenary), I would have thought twice before accepting the offer.
There was talk of a new rail line to the south of Rochester, MN a number of years ago and some landowners were unhappy because the proposed line would split their fields, require new fencing to protect livestock, etc.
Would it be easier to force a half a dozen farmers/landowners to give up part of their property than thousands of house/apartment dwellers? Of course. But its still forcing people and that results in lawsuits which will drag things out.
For me, 'restart' is generally the most used operation during debug. The vast majority of the time I want to rerun through the init code to clear out the registers and any previous transactions. If I've set something up incorrectly, I can always set a breakpoint and adjust.
So I'm not seeing an immediate benefit to direct modification for my normal workflow. There may be good use cases when writing code that isn't HW dependent or if the compile/flash cycle takes a long time, but those aren't problems I've had very often over the last ~10 years.
In addition, usually when I do something wrong in an embedded system the only way to recover is a hard reset and reload. Mishandled interrupt, corrupted stack, jump to a random location, etc.
In embedded systems, there are an infinite number of ways to crash such that there is only one way to recover (reset and reload). There are very few ways to crash that leave a non-reset recovery.
Interesting, I guess it depends on "how embedded" you are. For linux-based routers/gateways (edge of embedded really) the compile-flash-boot cycle can be rather long, but the standard workarounds (scp-after-build or NFS mount a work dir) work adequately.
That said, anything which reduces cycle times is good.
From what I've seen at IBM/HP, interns/coops usually get paid somewhere around $20 to $25. A bit lower if a freshman, higher if grad student. And last I heard, the MECOP program at Oregon State sets a floor of $15 an hour for interns and it sounds like the vast majority, if not all companies, pay more than that.
So while not an apples to apples comparison, I'd say at $15/hour you're low assuming no equity. That said, unless you need the money to survive, I would view the job as a springboard to your future goals.
So if you're learning a lot and enjoy what you're doing, I'd recommend sticking around. Maybe you can make a play for some equity? On the other hand, if you don't feel like your skills/resume are developing, consider looking for an upgrade (pay and personal development).
On the last point, I've been out of college for almost 10 years now and I still pick up quite a bit from my coworkers. It sounds like you're developing on an island which is both good and bad. You learn a lot, but you also miss out on the expertise of others. Something else to consider.
"If you have extensive and current open source contributions, for most people it means ... you're violating your employer's contract terms."
Bingo (at least for me). Both companies I've worked for require you to submit a proposal to an open source review board for approval. I went through the process at my previous job and approximately 2 months later I was given the go-ahead. Not worth it.
These days it often can mean quality bug reports. Many popular open source projects are more responsive to pull requests than simple tickets, so it's entirely possible to have a Github account which is used only for support with opensource projects which your employer relies on.
I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60% was probably a good year.
I worked on i&p series servers at IBM and a vast majority of what we did wasn't really new functionality. It was more adapting the existing code base to the next gen hardware. Power on sequences had to be modified, hardware access went from GPIO to I2C and vice-versa, and the rules of what could be plugged into where under what conditions were always changing.
And once everything was working, you've got years of support to look forward to. It wasn't uncommon to get pulled into discussions for products released 5+ years ago.
As an aside, hardware enablement might not be flashy work, but it can be loads of fun even if you're not writing massive amounts of new code. Sure, the documentation stinks and the first pass of hardware is about as good as airport TP, but it is amazing feeling when it finally works.
If you mean the idealistic notion that an engineer can come in and eventually run the company, sure, if they get on the management path quickly.
Spent just under a decade with IBM working on servers and even the best people I saw (technically and politically) were taking 8+ years as engineers to make it to a senior level (band 9 for any IBMers). And at that point, you're likely just a glorified project manager. If you put together a couple decades of awesomeness, maybe you make Distinguished Engineer or even IBM Fellow. They don't end up as VPs or CEOs.
As a disclaimer, I now work at HP. With respect to the culture in the trenches, I see IBM and HP as almost identical. Some great people to work with, interesting projects, and way too much bureaucracy :)
Also appears to be a small benefit from modifying the Lev struct to have Room first.