Am I unreasonable to think this seems crazy in terms of:
- owning their test coverage and and any related test failures within our org (i.e., blocking production deployments, etc.)
- dealing with any current/future namespace conflict with their source file names
- just generally our 'owning' these assets as if we had developed them ourselves
I've never heard of a vendor providing a Salesforce integration/installation like this before (versus providing a managed package via the AppExchange which is subsequently configured within our org).
We've already inherited a complex org in terms of coding customizations and test coverage issues, so I might be particularly sensitive to adding additional code/complexity that we would have to take the time to review ourselves and support going forward.Even if we ultimately agree that their source is a 'reference implemention' that we will enhance/extend, shouldn't they be providing it as an unmanged package at the very least?Thanks for any perspectives and thoughts.-L1 Antwort
I have experienced this with some vendors in the past. Typically they do this because they have been doing it that way for a number of years and haven't ever spruced up their methodology. It shouldn't cause namespace errors (becasue being unpackaged - it has no namespace) and they *should* be in charge of the code coverage for those classes they provide. Ideally yea you would get this in an unmanaged package (I would expect from the sounds of it they intend to make some tweaks and updates to the files to enable it to meet your exact needs hence why it is not managed). You are not being overly cautious/sensitive just practicing good due diligence and governance (which is a VERY good thing). I would ask the vednor why they don't distribute it as a package and what they intend to change in it (if anything at all). But suffice to say you do not have to be too worried.