是否需要向客户披露项目中使用的所有框架/开源软件
有一天，当我面对 Csla 框架中使用的验证代码时，我感到很惊讶。 感觉就像我因为没有向客户透露框架的使用而受到谴责。
这和使用 jQuery 等库不一样吗？
Taken aback to day when I was confronted about the use of validation code used from the Csla framework. It felt like I was reprimanded for not disclosing the use of the framework to the client.
Is this not the same as using libraries such as jQuery etc?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
IMO，你绝对应该承认你正在使用什么。
一些客户可能有特别严格的法律要求（无论是否出于合法原因 - 他们是客户，你不能判断他们的外行人），并且详细说明你用来为他们创建产品的任何第三方软件似乎只是合理的。
您有什么理由不愿意向您的客户开诚布公？
You absolutely should acknowledge what you're using, IMO.
Some clients may have particularly strict legal requirements (whether for legitimate reasons or not - they're the client, it's not up to you to judge their laywers) and detailing any third party software you're using to create a product for them seems only reasonable.
What reason could you have for not wanting to be open with your client?
这取决于您正在使用的开源代码的许可证。 其中许多要求您在某些制作人员部分中确认使用，其他要求您重新分发源代码等。您应该阅读许可证并采取相应的行动。
This depends on the license of the open source code you are using. Many of them require to acknowledge the use in some credits section, others require you to redistribute the source code, etc. You should read the license and act accordingly.
这取决于项目、客户类型以及您签订的合同。 然而，对于向客户交付代码的典型顾问来说，我会说不，如果您因为没有使用 CSLA 之类的细节来打扰他们，就会受到谴责，这很奇怪。 这很奇怪。
It depends on the project and the kind of client and whatever contracts you had. However, for a typical consultant delivering code to a customer, I would say no it is very strange that you would be reprimanded for not bothering them with details such as the use of CSLA. That's pretty odd.
是一样的，我有一种感觉，你也会因为使用 jQuery 而受到谴责。 有些企业出于各种原因不赞成使用开源。
它们归结为
您应该知道您的客户/雇主对此的立场是什么。 如果他们没有立场，那么你就必须根据具体情况进行讨论。
我通常告诉人们我使用了大量开源软件，通过看到我得到的回应，我知道要遵循的路径。 如果他们一提到开源以及缺乏支持之类的事情就跳起来尖叫，我只是倾向于要求预算来购买商业组件，或者提供很好的案例来说明为什么开源版本的 X 比商业版本更好。
It is the same, I have a feeling that you would have been reprimanded for using jQuery as well. There are enterprises that frown upon the use of open source for various reasons.
They boil down to
You should know what's your customer/employer's stance on this. If they don't have a stance, then you have to discuss on a case-by-case basis.
I usually tell people I use a lot of open source and, by seeing the response I get I know the path to follow. If they jump and scream at the mention of open source and the lack of support and whatnot, I just tend to ask for budget to buy commercial components or present good cases as to why the open source version of X is better than the commercial alternatives.
这在很大程度上取决于项目的类型和客户的类型。 这里真正的问题是你感到惊讶，这表明与期望不一致。 客户具体是如何激发对 Csla 的兴趣的？
It very much depends on the type of project and the type of client. The real problem here is that you were surprised, which indicates non-alignment of expectations. How did the client motivate its interest in Csla specifically?
如果您的客户需要了解或关心您使用哪种技术，那么您应该将所有内容指定为项目文档的一部分。 如果清楚地描述了这些选择，那么如果需要的话，就可以更容易地对其进行讨论。 文档还为您提供了一种要求（字面意思）“签字”的方法（如果您就是这样工作的话）。
从您的问题来看，尚不清楚问题是否出在框架的选择上，或者是否没有通知客户。
即使在文档最少的项目上，如果客户拥有代码，那么我总是至少提供一个高级架构文档，其中包括所使用的每个软件组件的名称和确切版本，以及简短的描述它的用途以及为什么选择它。 这也是解决任何许可证问题的正确位置。
If your client needs to know or cares about which technology you use, then you should specify everything as part of the project documentation. If the choices are clearly described, then it is easier to have a discussion about them, if required. Documentation also gives you a way to ask (literally) for 'sign-off', if that is the way you work.
From your question it is not clear whether the problem was the choice of framework, or not having informed the customer.
Even on projects with minimal documentation, if the customer owns the code then I always deliver at least a High-level architecture document that includes the names and exact versions of every software component used, along with a brief description of what it is for and why it was selected. This is also the correct place to address any license issues.