请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 20
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
微信扫一扫关注!

1、前言


随着云IM的发展,已吸引越来越多有IM需求的APP接入。但考虑到云IM无论从商业模式还是运营模式上,还需经过多年的沉淀,才可能真正实现客户与服务商的运营和服务良性循环的双赢局面。在此之前,加上有些场景下(比如为了信息安全而不允许接入第3方云IM的应用、IM作为公司核心技术发展而不考虑用云的情况等)也确实不适合采用云IM,所以目前开发完全自主IM的需求和动力依然很旺盛。

但要想做好全功能、全平台的IM,没一定的技术积累,显然是很难驾驭的了。正如TeamTalk的服务端设计者所说“IM的开发,从功能抽象的角度看可能非常简单,可以认为是管理大量的客户端连接和在不同的客户端之间传递消息,但具体到实现细节就比较复杂了。打个不恰当的比喻,OS的功能抽象也非常简单,无非是进程间的调度和硬件资源的管理,但要是自己去实现一个,一般人也就只能呵呵了”。

有鉴于此,很多团队开发自主IM时,都会首先想到在开源IM的基础上修改后,作为已用。但话虽如此,靠谱的支持全平台的开源IM,少之又少,这其中,蘑菇街开源的TeamTalk勉强算是一个。但正如国内大多数的开源工程一样,对已无利的事,很少会有人真心坚持的下去。

本文将简要介绍TeamTalk开源的过去和现在,为打算研究和采用TeamTalk的同行提供一定程度的参考。文中所涉及内容如有不妥,还请各位看官见谅。

2、TeamTalk相关资源


8542441.png 官方网站:http://mogu.io/
官方Blog:http://tt.mogu.io/
曾今的管理者的Blog:http://www.bluefoxah.org/
Github地址1:https://github.com/mogujie/TeamTalk2015年5月后
Github地址2:https://github.com/mogutt2015年5月前

** 后续补充:“蘑菇街TeamTalk”2015年5月前未删减版完整代码 [附件下载]

3、版权纠纷:源码存在版权纠纷,使用有风险


3.1到底发生了什么?


源码被Github下架后TeamTalk的网站给出的申明,截图如下:
5459e73d9cfc1_middle.jpg

3.2来自官方的访谈和回应


作为蘑菇街官方对TeamTalk源码与网易泡泡版权纠纷的回应,以下是对蘑菇街研发部架构师月明的访谈全文,现摘录如下:

2014年10月底,蘑菇街开源了其内部即时通讯软件TeamTalk,TeamTalk是一款企业办公即时通讯软件,目前支持所有的主流平台。正当开发者大赞蘑菇街的开源举措时,TeamTalk于11月4日晚被GitHub下架,原因是TeamTalk牵涉网易POPO版权。这一系列事件不禁让我们想到开源的底线还应该是尊重,目前具体情况还在调查中。本次访谈了蘑菇街的研发部架构师月明,以深入剖析TeamTalk背后的细节。

Q:请先介绍一下TeamTalk这款产品以及蘑菇街开源TeamTalk的初衷。
A:TeamTalk是一款企业办公即时通讯软件,由蘑菇街技术团队几位工程师利用业余时间开发完成。在开源之前,主要用于蘑菇街内部的在线沟通。蘑菇街在创业前期拥抱开源社区并使用了很多开源软件,这些开源软件帮助我们能够在技术资源有限的情况下很好的支撑了公司业务的快速发展,在技术团队发展壮大的过程中,我们逐步有一些的技术沉淀和积累,抱着感恩社区回馈开源的心态,我们希望能够把一些优秀的软件回馈给开源社区,不止TeamTalk,后续我们还会陆续推出服务化框架等更多的开源项目。

Q:请介绍一下TeamTalk的架构,这么一个支持多平台的产品,开发需要投入很多人力吧?
A:TeamTalk的架构设计主要是参考借鉴了蘑菇街自身线上IM的架构,考虑到消息类业务应用的特性,设计上优先考虑安全性、可用性、可伸缩性。设计的定量指标是平均单机10W并发用户以及千万级并发在线。

从前往后看的话, 前端有支持多平台的客户端,包括Android、iPhone/Mac、Windows、Web,后端是负责登录和负载均衡的LoginService,负责消息通信的MsgService,负责调度管理和集群扩展的RouterService,负责业务逻辑的BizService,负责存储服务的StorageService,以及其他系统类服务(监控服务,配置服务,日志服务,文件传输服务)。 具体详细的架构设计图,大家可以通过我们的GitHub查看细节。

TeamTalk最早的代码是从蘑菇街线上IM的一个分支拉出来的,现在主要是有5位工程师在贡献代码,他们大部分都是身兼多职的全栈式开发工程师,毫无疑问,现有的人员投入是远远不够的,所以希望能有更多的人加入TeamTalk开源,一起开发和维护TeamTalk。

Q:在开发过程中,是否有借鉴其它IM软件?相比来讲,TeamTalk有何优点?还有哪些方面需要改善?
A:刚才已经提到在架构和代码方面最大的借鉴是我们自己线上的IM,这个线上IM主要是服务于蘑菇街自己的商家和用户之间的闭环交流,在产品体验操作上,我们参考了QQ、微信等一些产品的做法,这也是让用户的操作习惯能够保持一致。

同比其他IM软件,个人觉得TeamTalk的优点主要有以下几点:

  • 1)开源:开源意味着免费和自定义开发,从客户端端到后端,每一部分都开源,社区的力量能够帮助它走得更快更好,也能够帮助一些企业和开发者快速搭建自己的IM应用和服务。
  • 2)跨平台:多平台客户端支持,PC下的Windows和Web页面,移动化方面的Android和iOS都能够很好的支持,符合当前应用全端的趋势。
  • 3)高安全性:通过对协议和数据的抽象分层设计,支持自定义协议传输和数据包加解密处理,支持消息阅后即焚功能,支持数据自定义加解密存储。
  • 4)弹性伸缩:通过对后端服务的高度分层和应用功能单一化处理,隔离消息通信处理和消息业务处理,使得运维成本,硬件成本降到最低,保证弹性伸缩。
  • 5)高可用行:通过LoginService的排队机制和负载策略,MsgSerivce/BizService的多实例配置,RouterService的调度和集群管理避免单点,保证了系统的高可用性。

TeamTalk的不足还是很明显的,存在以下几点:

  • 1)缺人:团队在软件开源管理方面经验比较少,缺少社区开源这块经验丰富的运作人员,也缺少能够贡献代码的开发者。
  • 2)功能不够完善:TeamTalk作为全新的IM开源软件,目前只具备了语音、文本、表情、传图等基础IM业务功能,功能还不够强大,框架层面,我们也只是做了比较基础的部分。
  • 3)文档和注释不够规范:之前开发得比较急,很多代码的注释不够详尽,文档也比较粗糙。

Q:TeamTalk是如何保证消息的安全性以及可靠性的?
A:刚说到TeamTalk优点的时候也提到了安全性,我们通过对消息数据的在系统中6个生命周期:数据录入、数据封包、数据传输、数据解包、数据存储、数据展现进行了细致划分,从协议和数据两个维度出发做了高度抽象分层设计,采用了自定义协议和自定义数据封解包处理。

为了节省网络流量,TeamTalk的协议是建立在TCP上的自定义二进制协议,TCP协议栈保证了数据的可靠传输。但是由于移动设备的网络不是很稳定,经常会出现一些连接超时断开的问题,我们对消息的传输又做了应用层方面的Ack机制,这样当客户端没有收到服务器的Ack,会提醒用户消息发送失败。以后还会考虑加入send-wait这种机制来确保消息的可靠传输,即在发送下一条消息前,已经确保收到了前一条消息的Ack。同时考虑到有些内网只支持HTTP穿透,我们后继会考虑支持HTTP长轮询接入,蘑菇街线上的服务器已经支持这两种模式。

Q:TeamTalk未来的发展计划是什么?会增加哪些新功能?是否会搭建云IM服务器为大家所用?会推出付费服务么?
A:从长远角度,我们的目标是希望TeamTalk能够成为企业和开发者搭建自己IM的首选软件,这个是理想。回到现实的话,半年之内,我们希望能够完成以下几个里程碑:

  • 1)社区:有一个相对稳定活跃的社区,有一帮志同道合热爱IM热爱开源的小伙伴很重要。
  • 2)文档:GitHub上的文档和注释能够相对规范完善。
  • 3)服务:对外提供公有云服务,切实的帮助中小企业和开发者快速以最小时间最小人力成本搭建自己的全端IM服务。

对于TeamTalk的新功能,由于TeamTalk支持插件式功能开发,所以我认为在开源的背景下,这个不是第一要位的事情,我想每个开发者都会很想给自己的女神开发一个摇一摇插件,发挥大家的能动性就好。TeamTalk付费服务暂时不在我们考虑中。

Q:11月4日,TeamTalk相关的仓库都已经被GitHub禁用,GitHub官方解释是TeamTalk的架构、通讯协议以及部分代码都有抄袭网易POPO之嫌。能解释下这件事情么?目前准备怎么处理?
A:TeamTalk做出开源决定的初衷,是因为我们在创业初期也使用了很多优秀的开源软件,所以想把一些优秀的软件也回馈给开源社区。4号11点多我们突然发现被下架的情况,之后收到GitHub的下架通知,大家也非常重视,毕竟TT凝聚了工程师们的大量心血。但恰逢双十一,而且这个双十一是蘑菇街上线自己的电商交易平台以来的第一个双十一,我们主营业务的开发压力非常大,为了尽快排查TT被下架的细节情况,澄清事实,解决问题,我们已经安排了专人在仔细地检查代码,并和GitHub以及POPO团队进行积极的沟通。但从现在的情形看来,还需要多一点时间。

我们已经向GitHub提出了申诉,同时,如果排查的结果确实存在版权问题,我们会做出公开道歉并制定惩戒方案。

4、源码割裂:混乱的源码管理


4.12015年5月前的TeamTalk


笔者清楚的记得,TeamTalk开源之初的github托管地址是:https://github.com/mogutt,源码和文档都是很齐全的(** 后续补充:“蘑菇街TeamTalk”2015年5月前未删减版完整代码 [附件下载]),比如下面的截图:

QQ20160723-1.png
QQ20160723-0.png

文档和说明还算齐全,你还能在Github上找到当初的fork版本,比如下面这个:https://github.com/lizj3624/https-github.com-mogutt-TTServer

4.22015年5月后的TeamTalk


现在的TeamTalk托管在Github上的地址是:https://github.com/mogujie/TeamTalk,大致翻了下,源码和文档跟当初https://github.com/mogutt相比,源码先不说,至少文档上来看,比原先要简陋了很多:

QQ20160723-2.png

4.3此源码可能已非彼源码!


鉴于发布之初与网易泡泡的源码存在很大的纠纷(说白了很可能是网易泡泡的离职人员直接使用了POPO的代码),2015年5月后的源码(就是现在的官方托管地址:https://github.com/mogujie/TeamTalk)可能已非当初的源码,具体能不能用,还有多少借鉴价值,就不得而之了。(** 后续补充:“蘑菇街TeamTalk”2015年5月前未删减版完整代码 [附件下载]

5、管理之争:TeamTalk开源管理者的离去


原先的管理者“蓝狐”于2015年7月31日发布的博文(地址是:http://www.bluefoxah.org/teamtalk/another_tt_roadmap.html)中称:

自从离开蘑菇街之后,蘑菇街收回了我的github代码提交权限,这让我非常诧异,TeamTalk是一款开源的产品,为什么所有的控制权一定要把控在某个公司手里?我心里知道这是谁的主意,也可以想象出来当时的场景。不过后面还是冷静下来思考良久。也许是他们担心TeamTalk的“荣誉”被我给“占领”了。我想说的是,既然是开源产品,就该本着自由,开放,共享,贡献,合作的精神来把TeamTalk发展起来,而不是在背后瞎BB。

虽然由于个人原因,离开了蘑菇街,但是一直关注着TT的发展,也一直努力去维护TT群的氛围,期间也在提交代码,但是却不明白“官方”为什么要收回我提交,审核代码的权限。


以上文字不多,但作为技术同行的你,应该能想见TeamTalk这背后的“人”和“事”了,各位自行猜测吧。

6、没有未来:已1年无更新的TeamTalk谈何未来


先不说现在的TeamTalk源码(地址是:https://github.com/mogujie/TeamTalk)跟发布之初的代码有多少渊源(当初涉及网易POPO的源码去哪了?),官方的Github仓库显示至少已超过11个月无人去管了:

QQ20160723-3.png

附录:更多IM开发精华文章


[1] 有关IM架构设计的文章:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信后台基于时间序的海量数据冷热分级架构设计实践
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?
IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议
IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token
WhatsApp技术实践分享:32人工程团队创造的技术神话
微信朋友圈千亿访问量背后的技术挑战和实践总结
王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等
IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
以微博类应用场景为例,总结海量社交系统的架构设计步骤
快速理解高性能HTTP服务端的负载均衡技术原理
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路
IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)
新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等
社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进
社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节
社交软件红包技术解密(四):微信红包系统是如何应对高并发的
社交软件红包技术解密(五):微信红包系统是如何实现高可用性的
社交软件红包技术解密(六):微信红包系统的存储层架构演进实践
社交软件红包技术解密(七):支付宝红包的海量高并发技术实践
社交软件红包技术解密(八):全面解密微博红包技术方案
社交软件红包技术解密(九):谈谈手Q红包的功能逻辑、容灾、运维、架构等
社交软件红包技术解密(十):手Q客户端针对2020年春节红包的技术实践
社交软件红包技术解密(十一):解密微信红包随机算法(含代码实现)
即时通讯新手入门:一文读懂什么是Nginx?它能否实现IM的负载均衡?
即时通讯新手入门:快速理解RPC技术——基本概念、原理和用途
多维度对比5款主流分布式MQ消息队列,妈妈再也不担心我的技术选型了
从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路
从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结
从游击队到正规军(三):基于Go的马蜂窝旅游网分布式IM系统技术实践
IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!
瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)
阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处
微信后台基于时间序的新一代海量数据存储架构的设计实践
IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!
IM开发基础知识补课(十):大型IM系统有多难?万字长文,搞懂异地多活!
阿里技术分享:电商IM消息平台,在群聊、直播场景下的技术实践
一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等
一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等
从新手到专家:如何设计一套亿级消息量的分布式IM系统
企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等
融云技术分享:全面揭秘亿级IM消息的可靠投递机制
IM开发技术学习:揭秘微信朋友圈这种信息推流背后的系统设计
阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路
阿里IM技术分享(四):闲鱼亿级IM消息系统的可靠投递优化实践
阿里IM技术分享(五):闲鱼亿级IM消息系统的及时性优化实践
阿里IM技术分享(六):闲鱼亿级IM消息系统的离线推送到达率优化
基于实践:一套百万消息量小规模IM系统技术要点总结
>> 更多同类文章 ……

[2] IM开发综合文章:
新手入门一篇就够:从零开发移动端IM
移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”
移动端IM开发者必读(二):史上最全移动弱网络优化方法总结
从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障
腾讯技术分享:社交网络图片的带宽压缩技术演进之路
小白必读:闲话HTTP短连接中的Session和Token
IM开发基础知识补课:正确理解前置HTTP SSO单点登录接口的原理
移动端IM中大规模群消息的推送如何保证效率、实时性?
移动端IM开发需要面对的技术问题
开发IM是自己设计协议用字节流好还是字符流好?
请问有人知道语音留言聊天的主流实现方式吗?
IM消息送达保证机制实现(一):保证在线实时消息的可靠投递
IM消息送达保证机制实现(二):保证离线消息的可靠投递
如何保证IM实时消息的“时序性”与“一致性”?
一个低成本确保IM消息时序的方法探讨
IM单聊和群聊中的在线状态同步应该用“推”还是“拉”?
IM群聊消息如此复杂,如何保证不丢不重?
谈谈移动端 IM 开发中登录请求的优化
移动端IM登录时拉取数据如何作到省流量?
浅谈移动端IM的多点登录和消息漫游原理
完全自已开发的IM该如何设计“失败重试”机制?
通俗易懂:基于集群的移动端IM接入层负载均衡方案分享
微信对网络影响的技术试验及分析(论文全文)
即时通讯系统的原理、技术和应用(技术论文)
开源IM工程“蘑菇街TeamTalk”的现状:一场有始无终的开源秀
QQ音乐团队分享:Android中的图片压缩技术详解(上篇)
QQ音乐团队分享:Android中的图片压缩技术详解(下篇)
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(上篇)
腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(下篇)
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
基于社交网络的Yelp是如何实现海量用户图片的无损压缩的?
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)
字符编码那点事:快速理解ASCII、Unicode、GBK和UTF-8
全面掌握移动端主流图片格式的特点、性能、调优等
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
自已开发IM有那么难吗?手把手教你自撸一个Andriod版简易IM (有源码)
融云技术分享:解密融云IM产品的聊天消息ID生成策略
IM开发基础知识补课(六):数据库用NoSQL还是SQL?读这篇就够了!
适合新手:从零开发一个IM服务端(基于Netty,有完整源码)
拿起键盘就是干:跟我一起徒手开发一套分布式IM系统
适合新手:手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)
IM里“附近的人”功能实现原理是什么?如何高效率地实现它?
IM开发基础知识补课(七):主流移动端账号登录方式的原理及设计思路
IM开发基础知识补课(八):史上最通俗,彻底搞懂字符乱码问题的本质
IM“扫一扫”功能很好做?看看微信“扫一扫识物”的完整技术实现
IM要做手机扫码登录?先看看微信的扫码登录功能技术原理
IM消息ID技术专题(一):微信的海量IM聊天消息序列号生成实践(算法原理篇)
IM消息ID技术专题(二):微信的海量IM聊天消息序列号生成实践(容灾方案篇)
IM消息ID技术专题(三):解密融云IM产品的聊天消息ID生成策略
IM消息ID技术专题(四):深度解密美团的分布式ID生成算法
IM消息ID技术专题(五):开源分布式ID生成器UidGenerator的技术实现
IM消息ID技术专题(六):深度解密滴滴的高性能ID生成器(Tinyid)
IM开发宝典:史上最全,微信各种功能参数和逻辑规则资料汇总
IM开发干货分享:我是如何解决大量离线消息导致客户端卡顿的
零基础IM开发入门(一):什么是IM系统?
零基础IM开发入门(二):什么是IM系统的实时性?
零基础IM开发入门(三):什么是IM系统的可靠性?
零基础IM开发入门(四):什么是IM系统的消息时序一致性?
IM开发干货分享:如何优雅的实现大量离线消息的可靠投递
IM开发干货分享:有赞移动端IM的组件化SDK架构设计实践
一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等
IM扫码登录技术专题(一):微信的扫码登录功能技术原理调试分析
IM扫码登录技术专题(二):市面主流的扫码登录技术原理调试分析
IM扫码登录技术专题(三):通俗易懂,IM扫码登录功能详细原理一篇就够
IM扫码登录技术专题(四):你真的了解二维码吗?刨根问底、一文掌握!
理解IM消息“可靠性”和“一致性”问题,以及解决方案探讨
阿里技术分享:闲鱼IM基于Flutter的移动端跨端改造实践
融云技术分享:全面揭秘亿级IM消息的可靠投递机制
IM开发干货分享:万字长文,详解IM“消息“列表卡顿优化实践
IM开发干货分享:网易云信IM客户端的聊天消息全文检索技术实践
IM开发技术学习:揭秘微信朋友圈这种信息推流背后的系统设计
阿里IM技术分享(六):闲鱼亿级IM消息系统的离线推送到达率优化
探探的IM长连接技术实践:技术选型、架构设计、性能优化
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:[转载] WebRTC开源5周年了,Google怎么看?下一篇:[思考] IM终有进化至消失的那一天

本帖已收录至以下技术专辑

推荐方案
评论 20
据说抄袭了网易POPO的源码,好歹网易泡泡还在运营呢,这样都敢开源,真是没法律决意识啊,还好网易没有深究,不然有人要倒霉了吧。
签名: 国庆长假还没有缓过来,请让我静一静,产品狗死远点...
原来如此,哈哈
签名: 星期六,那又怎样,还是得上班
Hi, 博主,我是蓝狐,关于您说的“管理者之争”这部分并不属实,我博客所提到的也只是代码提交和审核的权利(PS:当然当时由于比较愤怒,所以可能言语有些激烈,给大家造成误解很抱歉)。
引用:bluefoxah 发表于 2016-07-29 13:06
Hi, 博主,我是蓝狐,关于您说的“管理者之争”这部分并不属实,我博客所提到的也只是代码提交和审核的权 ...

好的,明白了,多谢回复 。
签名: 有点累,这周不想发新文了哦
其实挺可惜的
从:
引用:管理之争:TeamTalk开源管理者的离去

原先的管理者“蓝狐”于2015年7月31日发布的博文(地址是:http://www.bluefoxah.org/teamtalk/another_tt_roadmap.html)中称:

自从离开蘑菇街之后,蘑菇街收回了我的github代码提交权限,这让我非常诧异,TeamTalk是一款开源的产品,为什么所有的控制权一定要把控在某个公司手里?我心里知道这是谁的主意,也可以想象出来当时的场景。不过后面还是冷静下来思考良久。也许是他们担心TeamTalk的“荣誉”被我给“占领”了。我想说的是,既然是开源产品,就该本着自由,开放,共享,贡献,合作的精神来把TeamTalk发展起来,而不是在背后瞎BB。

虽然由于个人原因,离开了蘑菇街,但是一直关注着TT的发展,也一直努力去维护TT群的氛围,期间也在提交代码,但是却不明白“官方”为什么要收回我提交,审核代码的权限。

得出结论:
引用:以上文字不多,但作为技术同行的你,应该能想见TeamTalk这背后的“人”和“事”了,各位自行猜测吧。

并且给出了误导性的结论,这样做是不对的。

离职回收掉权限都是一件能理解的事情。
产生分歧的地方在于,回收不回收掉你的github上公司公开项目的权限。

这个很多时候都会有分歧。

公司宽松/严格就会导致不一样的结果,github有人管理/无人管理,也会导致不一样的结果。

无非是,公司觉得要回收,而个人觉得不应该回收,这里产生的分歧。扯到阴谋论其实并不好。
顺带说一下,很多公司,开发工作已经非常繁重,抽时间开源出一个版本已经是很难得了。

内部的和外部的还有很多区别,对外开源还要涉及到,去除敏感代码,去除内部代码,搭建服务器测试等操作。

pull request?严谨点的话,还要测试…

都不容易,就不要说别人坏话了。
挺可惜的,开源不易啊
签名: 该会员没有填写今日想说内容.
本来可以维护得更好的
签名:
可惜啊
可惜得很
开源不易
签名: 心情好
可惜了,好想学习一下源码
引用:asdf123456 发表于 2018-08-30 14:06
可惜了,好想学习一下源码

源码在这里啊:http://www.52im.net/thread-777-1-1.html
签名: 有点累,这周不想发新文了哦

开源不易

是啊,尤其在国内,做开源要顶着很多压力,还得防着伸手党、喷子。。。
签名: 有点累,这周不想发新文了哦
666
一会试试看能不能用。
谢谢分享。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部