开发人员 就相对的很好理解，就是以写代码或写文档的形式为项目做贡献的人们，他们有更加多样的参与项目的形式，如积极的在开发者邮件列表中、进行讨论、提交代码补丁、提交文档、建议、乃至批评。开发人员通常也被称之为 贡献者。
提交者
提交者 是指拥有代码仓库写操作权限的开发者，而且他们也签署了贡献者许可协议（CLA）文件，他们拥有以apache.org为后缀的邮箱地址，他们在提交补丁的时候，不需要依赖其他人，实际上他们可以为项目做一些较小的短期决定。项目管理委员会成员（PMC）可以同意（其实是默认）并批准某些开发者为提交者，可以是永久性的，当然PMC也可以拒绝某开发者成为提交者。这里请注意一点：是PMC做出决定，而不是某个独立的成员。
项目管理委员会成员
PMC 成员是由在项目的开发中表现突出的开发者或提交者选举出来的优胜者，他们拥有写入代码仓库的权限、以apache.org为后缀的邮箱地址、拥有社区相关事务的投票权、以及有权提出积极的用户参与提交。PMC 是作为其项目走向的唯一的实体，再没有其他团体可以参与。特别强调的是，PMC必须对其项目软件产品的正式发布进行投票。
项目管理委员会主席
项目管理委员会（PMC）的主席由董事会从PMC成员中任命。PMC 是整个项目的控制和领导的实体。而主席的作用就是充当董事会和项目之间沟通的桥梁，当然，作为项目管理委员会主席还有其它的一些特定的职责。
ASF 成员
ASF 成员 是由现在的成员所提名，然后根据对基金会的推进和演化来进行选举而定。ASF 的成员关注的是Apache 软件基金会本身，这通常通过项目相关和跨项目活动的根源来证明。从法律上讲，成员是基金会的“股东”，也是业主之一。他们有权选举董事会，成为董事会选举的候选人，并提出成为会员的提议者。他们也有权提出一个新的孵化项目（我们稍后会看到这意味着什么）。ASF 成员通过邮件列表和年度会议来进行日常的工作协调。
项目管理和协作Apache 的项目是基于共识的协作流程来进行管理的。Apache 是没有层级结构的，当然了，不同的贡献者群体在组织中拥有不同的权利和责任。
由于指定的项目管理委员会有权制定自己的自治规则，因此对于项目管理委员会如何运行项目及其所在社区没有单一的愿景。
同时，虽然存在一些差异，但所有项目都有一些相似之处：
沟通
沟通是通过邮件列表来完成的。这也就意味着，所有的“虚拟会议室”都是异步进行的，而基于此是因为当开发者们分布于世界各地时，就显得格外的重要。（而对于Apache的各个项目来讲，来自全球各地是常见的情况）
有一些项目还额外的使用，可以同步进行沟通的工具，（如IRC或其它的一些即时聊天工具），使用语音沟通的方式非常罕见，这通常是因为成本和语言上的障碍（言语比书面文本更难理解）。
一般来说，异步的沟通更重要，因为它可以创建归档（用于搜索和查阅），并且更加重要的是异步的通信方式符合社区志愿者的本性。
文档
每个项目都有其自己所负责的项目站点，更多信息可访问ASF 基础设施——那里有提交导师、开发者、PMC等相关的信息。
决策
项目通常是自我进行管理的，即由志愿者来驱动去做一些工作。这就是通常所说的”do-ocrac”模式，意即自己选择任务自己来完成，没有人分配也没有人监督。它通常运转良好！
当需要协调的时候，最终的决定采用的是较懒惰的共识法：一些没有反对票的正面投票就足够了。
投票的形式有下面三种：
+1 —— 表示同意的投票
0 —— 表示弃权，没有意见
-1 —— 表示反对
当投反对票的时候，要明确提出替代方案，以及投反对票的详细解释。社区然后试图就解决问题的备选提案达成共识。在绝大多数情况下，此方式可以解决导致投票反对的担忧。
此过程我们称之为：“达成共识”，而且我们认为这是一个让社区健康运转的重要标志。
原则（哲学思想）虽然没有明确的官方认可或指定的，但是以下六条原则是基金会背后的哲学的核心理念。这也就是被众人所称颂的”Apache之道”：
协作来进行软件开发
商业友好的标准许可证
要保持一贯的生产高质量的软件
尊重、诚实、以技术会友
忠实执行标准
安全性作为强制性功能
所有的 ASF 的项目都遵循这六条原则，同样，Apache 的项目需要独立治理，尽可能远离不合适的商业影响。
运营