许多大型组织都将IT部门locking到标准configuration，即SOE。 最终用户通常没有安装自己的软件的权利，即使他们这样做，组织也往往只允许安装“已批准”的软件。
即使对于免费/开放源代码软件，terminal用户通常也必须提交某种请求表格才能使软件得到validation和批准。 一旦遵循了这个过程并安装了软件，升级可能会很麻烦 – 许多组织都倾向于使用老版本的软件（Windows XP，Office 2003等），以免担心未知的问题。
软件开发人员可以做些什么来加快审批stream程？
如果您参与了这样的审批stream程：
我是跨国公司的软件批准小组的一员，我绝对会回应Adam上面所说的一切。
我还要提出以下几点，首先要支付所有的“开发税” 。 这意味着要确保您的应用能够在您可能无法使用的各种环境下正常工作，但很可能会成为大型企业的破产者，这些问题就像确保您的应用适用于漫游用户configuration文件以及redirect的用户文件夹（总是使用Windows API来查找用户和configuration文件文件夹，千万不要假设他们在标准位置，甚至在本地驱动器上），确保它在远程桌面服务器（可能有一个一次运行100个应用程序，一些使用非常缓慢的连接），networking连接速度慢或电池电量不足的笔记本电脑等等。 作为一个例子，我们最近拒绝了一个来自一个非常大的公司（从“A”开始，以graphics着称）的软件的新版本，因为他们的应用程序突然不能在最新版本的redirect家庭文件夹中工作，对我们来说是一个难题。
即使对于免费/开放源代码软件，terminal用户通常也必须提交某种请求表格才能使软件得到validation和批准。
按照您的评论的语气，听起来您认为审批过程与成本有关？ 从我们的angular度来看，应用程序的单位成本并不是我们在审批stream程中所能考虑的。 应用程序的理财理由已经制定出来，软件的批准都是从技术和支持能力的angular度来完成的。 免费和开源软件通常比专有的商业应用程序更容易通过我们的stream程。 通常这是由于缺乏问责制。 当应用程序出现问题时，你需要支持哪些人，他们的SLA是什么？ 当你需要了解应用程序是否可以与新版本的OtherApp vX一起工作时，你问谁，他们真的给你一个真正的答案，人们真的在努力，或者这是一个模糊的“社区中的某个人可能会做它“回答？
一旦遵循了这个过程并安装了软件，升级可能会很麻烦 – 许多组织都倾向于使用老版本的软件（Windows XP，Office 2003等），以免担心未知的问题。
软件升级必须经历与全新软件相同的过程。 他们唯一的好处是，我们已经知道了一些问题的答案，因为我们已经支持这个软件（这可能不是一个积极的软件，支持团队已经根据经验否决了升级公司）。
你喜欢MSI还是xcopy-able软件？
只要它们已经被正确打包，任何一种部署方法都可以很好。 否则，我们很可能会撕毁您的安装程序，并重新打包软件以供我们部署。
如果软件需要框架（Java，.NET）或多或less有问题？
这肯定更成问题。 在大多数框架中的版本控制和向后/向前兼容性是非常残酷的。 尤其对于Java来说，许多应用程序（和网站）都需要安装特定的主版本和次版本的Java，而不能与其他任何东西一起工作。 如果你需要在一台需要不同版本的Java的机器上安装三个不同的应用程序，并且他们不喜欢用一个Java版本作为另一个Java版本的标准方式，那么就会出现问题。 .Net在版本控制方面有自己的问题，但是很高兴让你安装所有主要版本的框架，
如果软件支持自动更新，你一般会允许吗？
决不。 有太多的版本和互操作性令人头痛，以至于无需任何警告即可让应用程序自行更新。 应用程序升级需要进行testing和规划。 具有普通用户权限的用户也无法应用更新。 如果您使用允许修补的部署方法（例如，将MSI与MSP修补程序一起使用），那么这可以使应用程序的安全修补程序远不那么头疼，我们可以使用我们的部署工具（WSUS和SMS）pipe理自动更新）。 另外，我们的安全团队非常怀疑任何可以“回复基地”的应用程序，他们喜欢确切地知道它发送了什么信息，以及为什么需要通过互联网向未知的服务器发送任何信息。
通常需要多长时间？
只要需要6个人点击Outlook中的“批准”投票button，就可以决定一些简单的应用程序和版本升级。 更复杂的或有争议的可能会等待我们的小组每两个星期开会。 一些应用程序可能会在这些会议中的多个会议上讨论，因为团队会对应用程序和研究/testing提出疑问。
你喜欢什么样的授权模式（可转换，每席位，每CPU，整个网站）？
完全取决于应用程序将如何使用，以及有多less人。 最重要的是你的许可证是明确的。 我们必须派遣我们的人员（尽pipe是免费的）课程来了解微软的许可。 我们不打算为ISV做这件事。
谈到授权时，请考虑我们无声的自动化安装需求。 如果您的许可证需要激活，我们不希望每次在PC上重新安装应用程序时都要响铃/发送电子邮件。 如果应用程序的每个副本都需要单独input不同的许可证密钥，那么我们不能自动部署该许可证密钥，而如果我们可以购买可以保存的批量（2,10,50,500等）密钥无声的安装，然后我们很高兴。 如果我们能在一年之后回到你身边，谈判扩大我们的许可证数量，而不必更改input到软件中的密钥，那更好。
ISV还有什么可以提高他们批准软件的机会？
我们也会看看那些与您的应用程序目前没有严格关联的东西。 请记住，如果您的应用程序成为我们某个地区的标准工作stream程的一部分，则可能会使用10年以上，那么您的产品的路线图是什么样的？ 如果您不支持最新的Windows或开发版Windows，您是否有计划？ 它看起来像你坚持这些路线图？ 它看起来像你有任何计划对你的应用程序进行重大改变，无论是它的工作方式或它使用的技术/框架？ 您的应用程序是否可以插入任何其他应用程序，例如MS Office或IE，如果有的话，这些应用程序的旧版或更新版本有多宽容？
我们是一个相当小的组织，但转移到标准桌面和批准的软件，以减less我们的pipe理麻烦。
你喜欢MSI还是xcopy-able软件？
任何可以执行“无声”安装的东西。 微星一般在这里工作得很好，但是很多安装软件也不错。 如果我们必须以某种方式configuration它，那么也可以通过xcopy-ing文件或registry合并来编写脚本。
如果软件需要框架（Java，.NET）或多或less有问题？
由于版本要求不同，可能会有问题。 如果你需要.NET 3.5，我们使用3.0，那么我们必须pipe理升级，并确保它不会破坏其他任何东西。
如果软件支持自动更新，你一般会允许吗？
没有。新版本导致问题的风险太大。 另外，用户没有pipe理员权限，所以更新通常不起作用。
通常需要多长时间？
如果业务需求紧迫，尽可能快 – 只要几个小时。 对于更尴尬的软件，也许一周或更多。
你喜欢什么样的授权模式（可转换，每席位，每CPU，整个网站）？
越便宜越好！ 我们可以处理最合理的select，但是如果软件进行任何types的自动检查或者需要激活，就会变得很困难。 这些并不能很好地处理死机，失败的激活等，而且通常会为我们做额外的工作。
ISV还有什么可以提高他们批准软件的机会？
有两件事情值得思考：
当然，你必须首先制作出值得使用的软件 – 如果用户真的喜欢它，他们会大喊大声批准！
我通常看的第一件事是 – 你有基本的权利吗？ 如果你做不到这一点，那么我将会非常不情愿地走下去。 所以我想看到一个标准的定制工具，让我build立一个转换的MSI安装程序。 我不希望看到任何安装或使用该软件的pipe理权限的要求。 我不希望看到重新configuration电脑的任何要求。 我不想看到每个用户的数据写入每个计算机的位置。 我不想看到手动访问桌面，我想看到通过GPO提供适当的远程pipe理和configuration。 换句话说，您是否了解托pipe企业部署的要求？
如果软件需要任何types的更新，最好是类似于AV定义文件或类似的东西，如果你愿意，最好能维护你自己的中央更新服务器，而且最好是完全明显地集中configuration。 我不介意随程序更新提供的软件，只要我可以closures它们。
我不想看到软件上的任何互联网通信，除了那些为了工作而绝对需要的。 最好全部logging下来。 通过让你的软件进入我的networking，我相信你们既不会搞砸，也不会做坏事，所以我希望你们不要背弃这种信任。 如果你这样做，我会非常失望。 请记住 – 你是我家的客人，请尊重我的房子。
没有JAVA 。 根据我的经验，Java在每次部署时都会造成严重的破坏，主要是通过解决上述所有问题。 我很高兴接受.NET，因为它至less似乎是从中央pipe理的angular度来看更加明智的devise（再加上.NET应用程序由于框架中的约束而获得更好的基础的机会）。
对于许可，我会寻找的第一件事是一个免费的试用版，我可以下载而无需注册。 如果我没有看到这个，我可能会怀疑你有隐藏的东西。 我没有时间限制，但我不喜欢减lessfunction; 毕竟，在这个阶段，我正在决定你的软件是否会成为我家里的一个可以接受的客人，所以我希望能够看到一切。
我想要一个单一的许可证密钥为我的整个网站。 必须在每台PC上input单独的许可证密钥才能打破“必须有中央pipe理/pipe理”规则。 为了自己定价，如果我只需要在200台电脑上安装软件，我就不会像在1500上安装软件那样花钱。
最后，持续的支持和维护是重要的。 总之，无痛地获取软件只是一件小事，但是如何在日常的日常使用中performance出来却是非常关键的。 如果我需要和你联系解决问题，我不会期望有任何障碍，而且我也不希望你在其他地方开始推搪，至less在调查之后才能确定事实。 我也丝毫不打算在维护合同中明显的企图撕毁我。
GAThrawn的答案涵盖了我要说的大部分内容。 我想扩大一些事情的许可方面。
应用程序需要打电话回家进行授权validation通常被拒绝。 如果你真的保护你的软件，请提供一个我们可以托pipe的授权服务器。 这可以是像FLEXlm这样的第三方解决scheme，也可以是你自己开发的东西。 FLEXlm在我们的环境中是最常见的。
并发使用许可选项总是一大优点。
如果您让我们托pipe许可证服务器，请确保它所通信的tcp / udp端口是可configuration的。 不要假设您的许可证服务器是唯一一个在包装盒上运行的服务器。
所有客户端/服务器交互都需要在没有任何最终用户交互的情况下完成。
生活在networking共享上的文本文件要求最终用户具有写入访问权限并不是可接受的许可解决scheme。 用户没有且永远不会拥有对我们的许可或应用程序服务器的写入权限。 我们不打算为你例外。 我不在乎你是否认为我们可以用配额等方法来locking它。 这是不值得的麻烦，你的软件并不重要。
我要先回答＃5，因为这对我来说是最重要的。
5。 ISV还有什么可以提高他们批准软件的机会？
您可以做的第一件事是通过Windows徽标testing。 “为Windows而devise”（或者他们今天所称的任何程序）程序testing了许多程序function和系统交互，如果按照规则编写，这些程序function和系统交互将减less我的工作，并确保用户的稳定性和可用性水平。
下面是其他问题的答案：
IT的function是部署和维护技术来支持核心业务。
对你而言，ISV意味着：
授权是取决于你所做的事情。 作为一个IT人员。 当您select采购软件解决scheme时，许可模式需要成为该stream程的一部分。 我们在采购中花费许可证pipe理费用，因此，如果您是像赛门铁克这样的公司，希望利用6种不同的许可证指标进行镍排放，我们的合规成本将会不利于您。 如果你是一个像微软这样的公司，你那令人难以置信的许可证过程太糟糕了，但是我没有select权……那么这只是成本的一部分。