rwhitman

I work for a development shop, and increasingly we have highly-technical software clients with legal counsel requesting that we do not use open source software without approval of the license by their team.

Now, the projects are largely Javascript (Node / React) based, and this gets unwieldily and puts burden on us to make sure our developers understand the license and what the client's legal team will support. Our engineers are not lawyers, they are not well versed in IP law and under time constraints, so its not uncommon to pick out a package without doing due diligence or submitting it for legal review.

A compromise we made with one client, was saying if the package manifest is available for review in Github then they can veto a package that they see as non-compliant or not up to par.

But some of our newer clients' legal depts are taking things a step further, expecting our team to submit the license for review / approval, and attempting to put the burden on my team for legal liability if an OSS license created a conflict later, redlining that into the contract.

This would create a whole new category of additional work and expense that would slow down timelines and inflate the cost beyond where expectations are set.

What is a good way to deal with this? I've chatted about it with our lawyers and other than fighting these redlines in our contracts, we're not clear on whats a reasonable solution going forward.

I'm overseeing an agency team who manage several webdev client accounts with ongoing support retainer contracts, all in a relatively similar tech stack and vertical. I'm working on optimizing our workflow with our project managers.

The tasks vary quite a bit and range from very minor cosmetic fixes, to resolving critical issues, to larger tracks of development.

This is my second time giving oversight in this scenario and I still feel as though I haven't seen a best practice for 2 core issues:

1) The correct way to triage tickets from many clients, with varying complexities, across the team.

2) Preventing developer burnout. The work doesn't involve a lot of innovation, mostly changing or fixing things, but some of it needs a pretty experienced developer to resolve. And the tasks often need quick turnaround time.

I feel like this is maybe a solved problem in other industries, but I have yet to be able to find a good resource on the best approach for web dev. Any tips?