春松客服开源社区组织原则
总则
第 一 条 为实现建设春松客服社区（以下简称"本社区"）的各方利益，以及完成社区的愿景，需要约束和平衡各参与者和利益相关者，特制定《春松客服开源社区组织原则》（以下简称"本组织原则"）。
第 二 条 本社区是平等的自由人联合体，参与者自愿促进联合体发展，目的是以下一个或两个：1）获得自身利益和保证该利益不受侵害；2）兴趣爱好、公益活动、社交等非利益。本组织原则是组织全体与组织中的个人订立的契约，每个参与方遵守本组织原则是本社区存在之基础。在本组织原则订立或修订后，必须执行本组织原则，按照组织原则行事。
第 三 条 本组织以民主、平等、公正为价值观，在此基础上投票通过原则订立和修订。任何利益、暴力胁迫或未经本社区表决所作之原则，均被视为不合法原则，契约立刻失效，相关权益立刻归还原主。
第 四 条 春松客服开源码发布使用 Apache 2.0 开源许可协议。
第 五 条 本组织原则面向社会公开（https://www.cskefu.com/community-constitution/）。
愿景和宗旨
愿景
第 六 条 公元 2032 年内 1000 万企业上线开源客服系统。
宗旨
第 七 条 普及科技造福企业的理念：
1）弘扬开源精神，践行互利共赢、共享互助的精神；
2）弘扬数字化技术，帮助企业长期稳定健康发展；
3）不断探索和应用前沿科学技术到开源客服系统中。
第 八 条 建立客服系统行业标准：
1）通过开源建立客服系统行业标准；
2）通过开源让中小型企业快速上线客服系统；
3）通过开源让客户、开发者参与客服系统定制和迭代。
组织架构图
第 九 条 春松客服开源社区中，包含的子组织定义：
1）春松客服用户组：包括上线或评测春松客服的组织或个人。扩大的春松客服用户组包括所有已上线或应上线客服系统的企业。春松客服用户组中，选举出用户代表。
2）春松客服开发者：日常工作的执行人员，参与完善春松客服社区和软件，为软件做贡献者。比如提交代码贡献的工程师、提交测试缺陷的质量保证人员、参加社区活动组织的运营人员等。
3）春松客服技术委员会：领导春松客服开发者实现愿景。人员从春松客服开发者选举而来。因早期春松客服开发者由少数积极贡献者自然形成，不由选举，而是由创建者组成。
4）春松客服道德委员会：监督、仲裁和制约春松客服技术委员会按照契约执行。
春松客服开发者
人员组成
第 十 条 春松客服开发者人数不限。
身份获得和撤销
第 十一 条 通过为春松客服提交设计规范、需求、代码、测试报告、性能报告、博客文章、使用教程视频等贡献后，在春松客服官网按照《加入春松客服开源社区》（https://www.cskefu.com/join-us/）指南完成身份获得。
第 十二 条 超过 1 年没有贡献者，自动解除身份。如曾担任春松客服技术委员会资格除外。
第 十三 条 担任用户组代表，自动解除身份。
投票权
第 十四 条 每两年召开春松客服技术委员会换届大会，参会者为自愿参会的春松客服开发者，选举新的技术委员会总工程师。
第 十五 条 决议春松客服开源许可协议。春松客服技术委员会如果提出更换春松客服开源许可协议，需组织春松客服开发者会议，至少提前 30 天告知所有春松客服开发者，是否更换根据全体投票，以一人一票原则，超过 2/3 接受更换则通过，立即生效。
其它权力
第 十六 条 经济收益权：在本组织原则和春松客服开源许可协议基础上，春松客服开发者（包括春松客服技术委员会成员）有权力通过技术支持和服务、OpenCore、云服务等通过开源延伸的商业模式（定义参考和范围参考附录《Open Source: From Community to Commercialization》），向需求方收取费用。该行为与春松客服开源社区无关。春松客服开源社区不承担任何法律责任。
第 十七 条 举报权：根据事实，向春松客服技术委员会举报因春松客服获得经济回报却对春松客服开源社区建设有负面影响的个别用户和组织；根据事实，向春松客服道德委员会举报春松客服技术委员会成员违反了本组织原则。
第 十八 条 知识产权收益权：如有使用春松客服开源码，并违反春松客服开源许可协议后产生了经济收益，扣除走法律程序及其他成本后，产生了因罚金而来的金钱等资源，则该财务曝光并全部投入到开源社区建设。
召开开发者会议
第 十九 条 春松客服技术委员会总工程师组织开发者会议，频率从每周到每季度不等，最小频率为每季度。春松客服开发者需提前计划，安排计划，积极参与会议。开会议题可通过 GitHub Issues 或春松客服邮件列表服务(https://lists.cskefu.com/) 提前发送给全体开发者。会议由一人主持，一人记录会议纪要（录音或录像），根据事情轮流发言。会议内容包括工作计划、工作进展、工作协作等。会后内容纪要由记录人发布到春松客服官网活动中（https://www.cskefu.com/category/conferences/）。
春松客服技术委员会
人员组成
第 二十 条 春松客服技术委员会人员不超过 7 人，包括总工程师 1 人，产品经理 1 人，质量管理负责人 1 人，以及业务专家至少 1 人，技术专家至少 1 人。
第 二十一 条 春松客服技术委员会人员不得同时担任其它开源客服系统或包括客服功能的开源应用软件的核心人员，比如贡献者、布道师、产品经理等。如有担任则立刻解除本组织职位。
身份获得和撤销
第 二十二 条 春松客服开源社区总工程师来源于春松客服开发者在技术委员会选举，该职位的首个担任者因为是春松客服发布者和社区的主要创办者，因此不经过选举。总工程师为社区第一负责人。总任期累计不超过
6 年。
第 二十三 条 春松客服技术委员会中，每届的其他职位设定和人选由总工程师提名，并经过道德委员会审议通过。春松客服技术委员会中，除总工程师外没有累计任期限制。
第 二十四 条 身份的撤销包括：
1）当事人主动辞任；
2）当事人同时担任其它开源客服系统或包括客服系统功能的开源软件应用的核心人员；
3）当事人因故无法履行职位内的责任；
4）被春松客服道德委员会撤职。
权力和责任
投票权
第 二十五 条 春松客服技术委员会成员可提议变更本组织原则，首先在技术委员会内达成一致，并通过春松客服道德委员会审议，道德委员会通过后生效。生效后，通知春松客服开发者。
第 二十六 条 春松客服技术委员会成员在日常工作中，有无法达成一致意见之事项，需要从本社区愿景出发：尽管不同意，但该决策确实是为实现愿景，那么也要支持和配合。如果做不到【不同意也配合】，则应请求道德委员会仲裁，接受道德委员会的方案执行。
履约责任
第 二十七 条 春松客服技术委员会履行、配合完成春松客服道德委员会发布之决策，如不履行按照渎职处理，立刻撤销该成员职务，该成员可根据资源收回权退出本组织。以下特殊情况除外：
1）决策与本组织愿景无关；
2）决策不利于本组织实现愿景。
其它权力
第 二十八 条 知情权：春松客服技术委员会内部分享春松客服开源社区产生的用户数据、商业机会线索、春松客服开源社区财务状况，以上信息皆属于机密信息，未经脱敏或技术委员会一致认可不得对外传播。
第 二十九 条 资源收回权：春松客服技术委员会成员不再担任职位，可要求撤回其个人或代表组织投入到春松客服开源社区的资源、资产。对于本社区无法撤出的资源，由道德委员会商讨解决方案，并立刻执行，技术委员会不得推脱。另有约定或已承诺永久捐赠给本社区的除外。
第 三十 条 提案权：春松客服技术委员会成员可提出修改本组织协议内容，在春松客服技术委员内部超半数通过后可提交给春松客服道德委员会审议，春松客服道德委员会行使修订权，驳回或通过修改提案。
不同职位
第 三十一 条 总工程师：社区第一负责人，保证日常工作按照本组织原则进行；代码库管理权，对代码合并权限、分支权限、发布权限等代码相关进行管理。
第 三十二 条 产品经理：社区第二负责人；保证产品规范，产品路线图，产品开源和非开源界限；组织、发布和梳理项目需求；产品研发工作总协调员；如涉及社区商业服务，产品经理同时是总项目经理。
第 三十三 条 业务专家：负责对内和对外的布道、需求分析、整理和分析解决方案等；进行演讲、文案等。负责和用户的业务代表接触和联络。
第 三十四 条 技术专家：负责对内和对外的布道、技术架构分享等；进行演讲、文案等。负责和用户的技术代表接触和联络。
第 三十五 条 质量保证负责人：领导社区完善春松客服单元测试、功能测试、系统测试、压力测试。设计和发布春松客服测试用例；召集和协调测试、试用用户；汇总测试报告结果；生成测试质量报告，用于评估发布风险；组织产品质量保证研讨会；促进春松客服自动化测试框架。
召开技术委员会议
第 三十六 条 实行周、双周或月为频率的技术委员会议，由技术委员会成员轮流主持。会议由一人主持，一人记录会议纪要（录音或录像），根据事情轮流发言。会议内容包括工作计划、工作进展、工作协作等。会后内容纪要由记录人发布到春松客服官网活动中（https://www.cskefu.com/category/conferences/）。
春松客服道德委员会
人员组成
第 三十七 条 春松客服道德委员会人数不少于 3 人，不多于 5 人。担当成员需年龄大于 40 岁，品德美好，社会阅历丰富，对春松客服开源社区没有直接或间接的经济关联。
第 三十八 条 春松客服道德委员会内部决定委员间工作关系，比如是否设定首席委员、会议召集负责人等。
身份获得和撤销
第 三十九 条 春松客服道德委员会候选人由春松客服技术委员会总工程师提名，经其他春松客服技术委员会成员一致通过后获选。
第 四十 条 春松客服道德委员会没有任期时长限制。如因当事人有以下情形，则撤销职务：1）个人身体健康、工作原因无法履行职责；2）与春松客服产生经济关联，则撤销职务；3）因违法犯罪，在司法机构或公安机关有犯罪记录。
权力和责任
第 四十一 条 匿名权：春松客服道德委员会成员可要求春松客服开源社区不公开其姓名、联系方式等个人信息到互联网等社会公共渠道。当事人也可以要求在春松客服开源社区和社会公共渠道中使用化名。
第 四十二 条 撤职权：经春松客服道德委员会一致通过，可撤销任何春松客服技术委员会成员职务。撤销原由需以本协议为基础，包括但不限于：
1）该成员超过 3 个月无法履行职位责任；
2）该成员严重违法组织愿景，做与愿景背离行为，比如散播言论攻击本组织；
3）该成员故意对外泄露未经春松客服技术委员会一致允许的机密信息；
4）该成员在公安机关或司法机构产生违法记录；
5）该成员因春松客服而得到巨大回报而不持续、积极的建设社区；
6）该成员之主要活动未对实现组织愿景形成积极贡献，包括但不限于传播危害国家安全政治敏感话题、引起其他成员不适的民族偏见等。
第 四十三 条 协商权：对春松客服技术委员会成员之间的冲突、不一致意见进行协调，帮助达成一致。对无法达成一致情形，春松客服道德委员会可使用仲裁权。
第 四十四 条 仲裁权：经春松客服道德委员会一致通过，可对春松客服技术委员会成员之间的冲突、不一致意见进行仲裁，做出最终决策。对拒不支持和配合仲裁决策的春松客服技术委员会成员，在对执行仲裁决策产生消极影响情况下，该春松客服技术委员会成员即视为违反本组织原则，组织与其之间契约失效，其失去春松客服技术委员会成员资格。
第 四十五 条 修订权：春松客服技术委员会提案修改本组织原则，经春松客服道德委员会一致通过后，可修改本组织原则内容。
召开会议
第 四十六 条 春松客服道德委员会内部决定何时何种方式举行会议，是否记录、录制。
决策形成
第 四十七 条 春松客服道德委员对处理事情进行内部讨论，轮流发言和表态。对形成意见后进行投票，除本组织内明确需要一致通过外，道德委员会自行决定通过原则，投票原则应选择常见规范，如一人一票，或累计投票；过半数通过或过 2/3 通过等。
发布决策
第 四十八 条 春松客服道德委员会形成的决策通过春松客服邮件列表服务（发送邮件至 dev@lists.cskefu.com）进行发布。春松客服道德委员会有权利要求春松客服技术委员会在 5 个工作日内，通过一切渠道进行再次传播：春松客服微信公众号、社交网络社群（比如春松客服微信群）、春松客服 EDM 邮件通知、春松客服官网博客等。
春松客服用户组
人员组成
第 四十九 条 所有体验、使用春松客服软件的企业、组织或个人均可视为春松客服用户。在春松客服用户中：
1）未有意愿、或未有能力直接参与春松客服开源码改动（设计软件、提交代码、参与软件测试计划）；
2）只以需求方角色出现，希望获得免费或付费支持。
同时符合以上两点的企业、组织或个人，才被视为春松客服用户组内的用户。
权力与责任
第 五十 条 春松客服用户所具备的权力和责任在春松客服开源许可协议 - 春松许可证 1.0（https://www.cskefu.com/licenses/v1.html）中详细说明，在使用春松客服源码、软件包、镜像等形式时，用户即已经接受该许可协议协议。春松客服社区认为用户已经了解以及接受春松客服所使用的开源许可协议内容。
第 五十一 条 在使用春松客服时，春松客服开源社区假设春松客服用户已经了解和接受春松客服软件中涉及开源码与非开源码界限或原则。
用户代表
身份获得和撤销
第 五十二 条 用户代表从春松客服用户组选举出产生，并以个人身份担任用户代表。选举过程由春松客服技术委员会社区经理组织和主持。首届代表由春松客服技术委员会内讨论决定。
第 五十三 条 用户代表任期每届 1 年，每年进行换届，累计任期不超过 2 年。
第 五十四 条 用户代表不得同时担任春松客服道德委员会、春松客服技术委员会中任何角色。
履约责任
第 五十五 条 代表春松客服需求方，尽可能的给春松客服开发者提要求。组织或配合春松客服开发者举行春松客服用户会议。
第 五十六 条 收集、汇总整理用户对春松客服的需求、BUG、性能瓶颈等，与春松客服技术委员会一起商讨工作计划、产品路线图等。
权力
第 五十七 条 解读权：对用户需求的分析和优先级，在春松客服开发者会议中进行阐述和强调。并与春松客服技术委员会产品经理进行沟通，包括产品功能、优先级、开发周期、是否应开源等。
附录
Open Source: From Community to Commercialization
https://future.com/open-source-community-commercialization/
Support and Services Model
Support and Services was the model of the Open Source 1.0 era, and
RedHat has really cornered the market on this and achieved scale. If you
decide to go down this path, you will likely end up competing with
RedHat (which is why five years ago, I wrote the blog post "Why There
Will Never Be Another Red Hat: The Economics of Open Source.")
Open Core Model
The Open Core model, which layers value-added proprietary code on top of
the open source software, is a good model for on-premise software. If
you have super valuable components (such as security or integrations)
that can be kept proprietary without harming the open source adoption,
Open Core will be a fine model. A note of caution: with Open Core,
community alienation can become a problem when deciding which features
belong in which code. I saw that at my own company, and finding the
right calibration with the community was very important. The ultimate
pitfall here is that your community decides they don't like your
behavior on the proprietary side and they fork the project, or start a
new project around the same codebase.
SaaS Model
In a SaaS model, you provide a complete hosted offering of the software.
If your value and competitive edge is in the operational excellence of
the software, then SaaS is a good choice. However, since SaaS is usually
based around cloud hosting, there is the potential risk that public
clouds will choose to take your open source code and compete.