写在前面：

因为项目要求要学习mean，所以要从搭建环境开始，网上的教程不怎么多，但是感觉方法倒是不少，也没多想，就开始安装，运行起来发现怎么和安装教程中的目录结构不同？
想了好久，也翻看目录半天，总感觉怪怪的，是有些包没失败还是哪里出了问题，无意中看到一个人说的mean有两个github，如下：

创新互联专注于大英企业网站建设,成都响应式网站建设公司,成都做商城网站。大英网站建设公司,为大英等地区提供建站服务。全流程专业公司，专业设计，全程项目跟踪，创新互联专业和态度为您提供的服务

mean.io: https://github.com/linnovate/mean

mean.js: https://github.com/meanjs/mean

然后有一篇文章说明了两者的关系，也就是下面要翻译的文章，其实也不是翻译了，全当是好奇心驱使，想要搞清楚怎么会有两个mean...翻译水平自己都信不过自己的，大神路过轻喷，Just for fun

原文：Forking out of an open-source conflict

---

序言

两年多以来我一直是一位自由开发者，在这段时间里，我在工作中使用全栈的Javascript解决方案，涉及到MongoDB，Node.js和AngularJS
大约在一年前，我注意到当创建一个新的web应用时总是一个循环模式，而且我意识到我最近开发的三个web应用都是使用的相同的技术：使用MongoDB最为数据库，
Node.js和Express最为后端架构，AngularJS作为前端框架，我开始构建一个样板来帮我应付这类工程，而且我很高兴能看到别人也注意到这样的开发模式。
经过谷歌搜索，我发现了瓦列里·卡尔波夫的MongoDB博客文章建议使用MEAN名称，
到目前为止，这是我发现的最早提及mean名称的地方了

大概在10个月以前，我接手了一个名为Linnovate公司的工程，这个工程是Linnovate公司从别处接手的一个糟糕的mean变种，
他们希望我能组织它们，幸运的是，我已经拥有自己的样板，并且向他们进行展示，我们一起决定把它开源，不久之后，社区开始受到样板，在hacker news上的第一个帖子得到我们的指引，
然后一些人开始在推特上关注这个项目，不久之后，出现了很多关于全栈方面的文章，MEAN开始蓄势待发

与此同时在Github上，我经历我的职业生涯中最好的一段经历。作为工程的维护人员，我发现了开源的真正力量，社区中好多好的开发者们帮助我学到了很多新的事物：从利基陷阱到大版本变更，
从管理工程到社区礼仪，所有的这些都使我更加充满编写代码的激情，我越来越多的参与到项目当中，比以往更加频繁的查看邮箱，经常调整问题页，测试提交上来的代码，这些事情成为我大部分的日常工作

冲突

直到去年年末之前一切进展的都很好，就是我将成为首席维护人员，Linnovate给我更多的时间，这相当的不错，因为公司在不牺牲核心利益的前提下能够更多的帮助社区，对我来说，我能保持独立，
然后能很好的维护这个工程，唯一为问题就是公司和自由开发者持有不同的议程，所以，在去年年底，我们的合作走到了十字路口

几乎在其它的专业领域这都将导致严重的法律纠纷，通常都将损坏双方的利益，幸运的是在我们开源社区，这将得到优雅的解决，在当前项目中分离出去，所以在一个月之前，我离开MEAN.IO并且成立一个新的工程叫MEAN.JS。
我叫来我的小伙伴同事科恩(最初MEAN贡献之一)来和我一起工作

结局

当我们走进MEAN.JS开发时，我们心中有一个主要的设计目标：让MEAN.JS从不断发展的黑客马拉松样板成为真正的生产框架，换句话说 - 我们想要帮助你说服项目经理是时候离开PHP。自从每个MEAN模块已经生产就绪，
问题就是要把他们正确的结合在一起，先把这些放在心里，我们指出一些问题：

模块化

为了使MEAN.JS变得优秀，我们需要把它分解成明确的模块，每一个模块支持一个主要的特性。我们还需要改编它使其支持创建合乎逻辑的模块。
所以，我们改变了一点工程结构去支持新的方法，一些文件被分割，一些被合并，不过总的来说我们做了主要两件事：

1. 我们改变后台结构使其支持MVC模型
2. 我们重组了AngularJS部分来支持垂直模块

我们也增加了一些自动加载模块特性来缓解开发过程，模块化是相当不错的，它也帮助我们解决另一个原MEAN的主要问题，传统支持

传统支持

一个原MEAN栈存在的问题是对以前的支持很弱，项目经常变更，没有版本方案产生很多的版本，很多特性添加或删除没有正确的通告，人们在升级他们工程时会遇到问题，
并且它通常会放下一些规则，所以我们从一些我们喜欢的框架中借鉴一些经验：

1. 版本号 - 像一些其它的框架一样使用奇偶数，一些版本号代表稳定版本
2. 分支 - 我们使用标签和分支来正确标记不同的变更和布丁来代替以前的直接合并
3. 模块化 - 把工程分割成多块使我们有能力去提交BUG补丁更快速

我们的愿望是能支持更多的受众，当然也包括原MEAN社区，让我们来处理下一个来自MEAN用户主要的抱怨，文档

文档

可能这是来自社区最普遍的需求，拥有正确的文档是任何一个可敬项目所必须的。我们建立了一个网站，
来提供这个栈的基本文档介绍建立样板，里面介绍了主要依赖和如何配置它们，MEAN.JS如何工作，
还有就是如何开始开发一个新的应用。你可以访问文档页面去发现更多的帮助，如果你还有其它问题，你可以直接向社区求助

社区

最后一块版块要说下如何为MEAN开发者提供更好的帮助，经过一些实验性的工具，最终我们决定使用已经公认的通信方式，
我们有了新的推特和一个Facebook页来更新新闻和一些讨论，建立MEAN.JS的google group来技术支持，并在#meanjs的IRC频道实时支持。
所以，请联系我们如果你还有进一步的问题

未来

关于未来的开发，我们会集中精力在下面的四个部分：

1. 核心 - 优化MEAN的核心，并修复Bugs
2. 模块 - 建立更多的模块来扩展MEAN，使其支持不同web应用特性
3. 产生器 - 我们已经开始建立期待已久的yeoman
4. Admin - 建立一个admin面板来管理你的MEAN应用

结语

离开原MEAN项目是我人生的最艰难的转折点之一，不过有些时候你需要冒险去支持你所坚信的。说了这么多，它按照我们所想象的那样自由地发展，
今天，我们带来MEAN.JS的第一个版本，邀请大家加入我们新的征程

Amos Haviv

MEAN的作者。

* 请随时问我问题，我将尽我大努力来提供你扎实的事实和真实的想法～

---

呼呼，好累，总算知道了这两个MEAN的区别联系，也算长了点知识。
之前一直纠结的项目中没APP目录是什么情况算是清楚的解决了，关于两个MEAN的结构也有了认识。
小憩一下，新MEAN，走起～

名称栏目：[翻译]MEAN.IO与MEAN.JS的前世今生-创新互联
网站路径：http://myzitong.com/article/jsgoc.html