“我们是否应该使用Drupal?”
“我们是否应该使用Drupal？”——这样的问题大家应该都不陌生，即使有人告诉你“应该”或者“不应该”，在你的脑子里也必定会有各种疑问，好像问题并不是像表面这么简单，答案好像也不是存在于“应该”和“不应该”之间。
如果你正被这个问题或曾经被这个问题所困扰，那么，接下来的内容你可能会感兴趣。
正如前面所说“我们是否应该使用Drupal？”这个问题并不是在问“我们是否应该使用Drupal？”，真正问题也许是——为什么应该使用Drupal？为什么不应该使用Drupal？以及应该怎么使用Drupal？
为什么应该使用Drupal？
这个问题实在是太简单了，不是吗？你可以去问任何一个选择使用Drupal的人、团队或者公司。不用太资深，他也能够讲得头头是道。没错，这就是Drupal的魅力，它实在是太好了，它能这样，能那样，几乎无所不能。—— Drupal 实在是太好了，这就是应该使用它的理由，大部分会提出本文开头问题的人也相应这一点，所以才会提出那样的问题。
但这个答案并不能回答那个问题，所以我们再看看“为什么不应该使用Drupal”……
为什么不应该使用Drupal？
不应该使用Drupal的原因有一点与应该使用它的原因是一样的，那就是他太强大了，他是整个Drupal社区的智慧结晶，熟悉它需要花费大量的时间和精力——这些时间和精力不是指学习它，因为学习任何一项技术并不比其它任何技术要难。
也许会有人讲到其它的原因，比如性能不好、版本不向后兼容、难以协作等等，这些也可能是阻碍你使用Drupal的原因，但无需在意这些问题。
也许你已经发现了，这些“应该”和“不应该”的理由对你来说并不足够？不是因为这些信息无关痛痒，而恰恰正是因为你觉得他们至关紧要，才会更加想要更多“我们是否应该使用Drupal？”的答案。而这样的答案即使给再多也不会够。
应该怎么使用Drupal？
对于有 R&D 部门的大公司，不必把注意力放在Drupal的技术点上，而应该考虑建立和运营自己的Drupal团队。因为Drupal已经提供了扩展性非常良好的研发标准和框架，这对项目的持续性、统一性以及未来的可持续发展性都提供了良好的保障。建立团队能够从人员方面更好的保证项目的稳定性和可持续性。
团队建立的具体做法有两种：一种是招募一位有能力的Leader，然后再通过招聘、培养的途径逐渐强化团队；另一种就是与有专业Drupal培训业务的公司达成合作，长期驻场进行项目指导以及团队培养，直至团队能够独挡一面。
对于有 R&D 部门但技术能力不够强、或经费相对有限的公司，建议将项目发给外包公司，并与之达成合作，在外包项目完结后，为你提供业务与技能的培训、咨询。通过外包公司完成项目整体的建设工作，并让自身的 R&D 团队掌握一定必须的Drupal技能，能够以较快的时间成本完成项目，并以正对较低的成本学习Drupal，以及对项目进行维护和二次开发。
对于没有 R&D 部门的公司/团队/政府部门，如果项目后期还会有较多研发需求，则不建议使用 Drupal。如果只是展示型或弱功能型的站点，可以将项目进行外包使用Drupal进行搭建，但意义也不大。Drupal 的最大优势在于其灵活性和可定制性，如果自身不使用这些优势去达成定制或节省长期成本的目的，将项目直接外包给任何能够以任何技术达成目标的团队似乎会更好。
附注：如果使用Drupal仅仅是因为它在全球范围内响亮的名号，那其实就不用纠结应该不应该了 :D
