前天有朋友转发给我这个话题，让聊聊我们的情况，语音沟通后最后还是决定整理成文字分享出来，希望能给准备做开源的小伙伴一些启发，在这里也希望能结交更多的开源伙伴。

　　我们目前正在运营一款开源电子签章软件，名为开放签开源电子签章。于2023年12月15日正式发布至gitee和github仓库，并在gitee上获得了676个star和352个forks。商业化方面，我们平均每周能够吸引2-4个付费客户，偶尔也会遇到大客户以项目制方式交付定制化项目和源码。对于软件的生存能力，我们只能说勉强够公司运营支出，还算不上富裕，还需要继续努力。

　　我们团队共8名小伙伴均出身于计算机专业。工作分工是这样的：5名主力负责日常编写代码；1名负责接收用户需求并进行产品设计和规划，同时协调5名主力的分工和代码联调；1名负责产品测试和客户前期的售前支持；1名负责销售运营和回答用户的日常问题，部分小伙伴同时也会兼些其他职务。

　　我们做电子签章项目的理由，我们的这8名同事都来自某家电子合同SaaS公司，几乎在2016年接触到电子合同这个行业。不幸的是，我们的电子合同公司于2019年并购了另一家电子合同公司。业务融合进行了大约三个月，在一个黑夜大家相互聊工作感受（那些经历过互联网公司交易并购的人应该会有同样的体验）..........于是，不约而同地，我们向公司提出了离职，于是就成立了这家公司。

　　公司创立之初并没有考虑到电子签章领域，主要是没有找到电子签章运营的新模式。团队成员主要是软件工程师，计划开发一个面向C端用户的小程序。然而，情况并不长久，在2019年底疫情爆发后，创业项目遇到了很多阻碍。因此，在2020年之后，团队开始承接软件项目，主要集中在电子签章方面。为客户提供平台搭建、集成e签宝、上上签的API接口，以及为用户选择电子合同供应商。此外，也承接了一些非电子签章项目。团队在2020年至2023年间共同度过这段时光，经历了迷茫和膨胀，也面临了各种项目挑战。幸运的是，成功留下了几家稳定合作的客户，确保了持续的合同收入。

　　有了之前电子签章SaaS和创业几年电子签集成服务的经验，在2022-23年制定企业运营规划时，大家提倡公司应该有一款主打产品，这样才能提升利润。作为一家一直从事软件外包的企业，心里有些不甘，最终还是选择了自己最熟悉的行业和产品（电子签），并确定选择以开源的方式运营产品，当时主要也是考虑了团队成员都有技术经历，也很符合从技术层面切入产品运营。于是，2023年团队开始做准备，进行技术框架的整理、团队的精简和产品的规划。历经两年，最终在2023年底，我们打造了一套电子签章PaaS平台，主要目标是支持多租户、可配置和本地化。同时，我们还选择从开源电子签章核心技术和组件的方式执行开源计划，并选择了MIT开源协议，让使用的用户没有版权的顾虑。

　　【为什么选择mit开源协议呢？更多的是为了情怀和信念。多年来一直致力于电子签章产品的开发和服务中，希望能够以我们多年积累的行业知识和技术，为软件厂商和更多像我们一样的小微企业做出一些贡献。让更多企业可以低门槛、便捷的使用电子签，让电子签可以更快速的普及。】

　　在选择开源这条道路之前，我们可以说挣扎了三个月时间，主要担心外界和同行的嘲讽。作为一支在电子签章/电子合同行业工作了八年的团队，我们对于市场上产品和运营模式有一定的了解。市场产品有面向国央企客户提供过软件+硬件解决方案，有面向中大型组织提供过全套电子签章业务系统，也有面向互联网企业提供过接口集成服务，更多的是提供SaaS订阅服务。此外，我们还调研了欧美和东南亚的电子签章企业，各种模式百花齐放、各有千秋，唯独在国内没有一家企业专门从事开源电子签章服务的公司。

　　毕竟，有些很多企业在购买电子签产品和服务时，价格还是有一定的门槛。我们希望能够让大家以低门槛的方式使用电子签章技术和产品。虽然网络中可以找到关于电子签相关的技术，但是非常的零散。开放签开源工具版对电子签核心技术做了全面的整理、完善和可应用于商业中的技术开发和处理，在网络和开源社区中应该是较全面的，使用开放签开源技术，有电子签需求的伙伴可以避免很多重复造轮子的工作，可以让更多精力放在自身业务开发中。

　　我们的目标是通过精良的电子签技术、工具与产品，通过开放签开源技术和工具构建专属电子签平台。通过开源模式，必定会降低用户使用电子签的门槛，加快电子签的应用速度。用户在开源模式下根据需要进行灵活定制和选择相应的电子签章技术，摆脱固定流程和模式的限制。

　　关于如何生存，文章在开头简单提到了公司目前有商业转化，这意味着公司能够继续生存下去。提到生存就不得不提到商业模式，公司目前有两款产品，一个是电子签名工具，另一个是签署平台（一套完整的电子签业务管理系统，正在准备发布开源版本）。

　　公司的营收来源于向企业提供本地化、专属的签署平台（可以与其他系统接口集成和OEM），客户需要支付软件授权费和第三方云服务费用（涉及数字证书、实名认证和短信等服务）。

　　同时客户还可以选择工具开源源代码，自建电子签功能或系统，主要是供有技术能力的团队或个人使用的。如果需要权威的CA证书，可以找我们代采。

　　根据目前的流量和用户反馈，如果想走开源路线，产品质量是关键，还需要耐心回答开源用户的问题。对于白嫖的问题，需要放平心态，要怀着包容的心态对待，因为这类用户也会起到宣传引导的作用。只有在产品被广泛的使用的情况下，才能越来越好。

　　同时，开源产品和非开源产品需要明确区分。我们也要感谢各个开源博主，他们帮我们转发博文，使我们的产品在开源市场有了声音。

　　如果全身心的投入到开源项目，那么就要考虑到商业转化的问题。现在开源模式无非是售卖专业版软件授权、提供技术支持、售卖技术文档、广告模式。无论开源与否，都应该要考虑产品是否能够为业务带来价值。对于商业化转换，尽量考虑企业侧用户，个人侧用户转换率比较难。

　　开放签仍处在开源项目的“婴儿学步期”，需要更多经验人士和开源团队分享交流这个话题，助力开源项目的顺利进展。我们相信“花若盛开,蝴蝶自来,你若精彩,天自安排 ”。

　　EasyGoAdmin 敏捷开发框架 GoFrame+EleVue 版本 v2.1.0 发布

　　开源日报 GitHub全站服务不可用；C++内存问题排查攻略；将网站迁移到CF省了几万；李沐创业一年复盘

　　:fire: Techempower 测试 Solon 为 Spring 的 300% 左右

　　Silverlight自定义数据绑定控件应该如何处理IEditableObject和IEditableCollectionView对象

　　WPF的消息机制（三）- WPF内部的5个窗口之处理激活和关闭的消息窗口以及系统资源通知窗口

　　Wijmo 更优美的jQuery UI部件集：通过jsFiddle测试Wijmo Gauges

　　Silverlight DataGrid使用WCF RIA Service实现Load-on-demand的数据加载

　　Spread for Windows Forms快速入门(15)---使用 Spread 设计器

　　Spread for Windows Forms快速入门(4)---常用的单元格类型（上）

　　Spread for Windows Forms快速入门(15)---使用 Spread 设计器

　　ActiveReports 报表应用教程 (10)---交互式报表之向下钻取（详细数据按需显示解决方案）

　　ASP.NET MVC 5 - 验证编辑方法(Edit method)和编辑视图(Edit view)

　　ASP.NET MVC 5 - 验证编辑方法(Edit method)和编辑视图(Edit view)

　　Table-values parameter(TVP)系列之三: 利用Collection将其作为参数传给SP

　　Spread for Windows Forms快速入门(5)---常用的单元格类型（下）

　　没GMS是借口，本质还是不想适配国内的手机系统，等鸿蒙Next出来，看微软拥抱不拥抱就知道了

　　只能说有外国人用，但不多，不说这些，但这个图标是真的好丑，桌面的默认壁纸也是。其他的没啥大问题。

　　这个还真不好讲。spring 的 web-flux 也是基于 netty 的。。。但是性能远不如 solon 的 web-rx 。。。当然 vert.x 是纯手写，没有注解。可能这里省了一层性能消耗

　　这个很有用 图形界面服务器内核panic之后 图形界面是卡死的无法动弹，没有有效信息 有了蓝屏就可以输出具体的错误信息了

　　“虽然两人只有大专学历”—— 大专也算高等教育，现在这些媒体口中已经文盲一个级别的感觉了吗？

　　Mac OS寄生在unix身上,android寄生在linux身上,Window抄袭Mac OS,Linux抄袭Unix....自己人搞鸿蒙你们就受不了了?

　　不管怎么样，在安卓和ios的夹缝中，敢于建立第三个生态系统，关键还建立起来了，这就newbee了；强如微软，当年也灰头土脸；那些吹毛求疵的，其实就是见不得自己人好。

　　文档整体看了，也深入细节看了，从规格上来看算是一个非常优秀的语言融合实践案例，但设计者仍稍显矫揉造作之嫌，搞了一些“创新”之举，比如func/foreign/-/prop/mut/Rune/:/...，除赋值操作符外，任何复合操作符都是不可接受的，宜尽量避免；在某些方面显得一致性不严谨，比如函数作为参数和返回类型时就与标准定义不一致，比如匿名函数（Lambda）定义也不一致，增加了代码阅读理解难度；C语言取址符号(&)作为接口继承用间隔符是个坏主意，因为这个符号在键盘上输入不方便，需要双键才能输入；Nothing/Option/Any 貌似取自TypeScript，其终归是某种类似于 Null 的检测机制，要不合成一个？类型在后并用冒号(:)分隔的语法风格上属于 Pascal/Go 风格，这种风格感觉是更方便实现词法分析器并生成语法树，利于后续的处理； 个人期望出现一门新语言，它应该以C语言风格为基础，大胆吸收新生代语言的优秀实践（语法糖），语言规格尽可能的保持精简和一致性，但语义和扩展性保持开放；仓颉语言为新语言开发做了非常伟大的探索和实践，实现后的预期也非常好，开了个好头；有了榜样的力量，相信中文社区有更大可能性诞生这样一门语言；

　　搞笑得很，不整理，不贴牌，就不让评论了？就是有一股邪气，一提意见，就要发言人都像你们这样那样，只想要点赞和吹捧吗？歪货就是歪货，装什么大半蒜

　　明明能躺平，明明可以割韭菜，还花钱研发？为了找骂？说这个能割韭菜？你被割了？你买了吗？是谁年年换mac，是谁年年换iphone？华为的用户好像没有那么干的吧？真让我一个小米用户都看不下去了！

　　一会Deepin v23，一会Deepin V23，一会又Deepin 23。你这个系统一点不讲究。版本号乱的一塌糊涂。

　　这个对比的条件还存在好几个问题。 1. solon使用的是smart-http，spring使用的是undertow 2. solon启动本身的自动配置少于spring 这两点就决定了对比的维度不同，性能更好的原因大概率是web服务器、应用配置依赖导致的。 如果要拉齐，需要使用同样的web服务器，spring应用排除掉所有的自动配置，只保留web必须的，才能说明框架的性能差距。 现在这个结果，无法说明solon本身性能好。

　　说的是事实就不能骂吗，周是流氓教父、做各种下三滥的事是不是事实？能力和道德无关，这里骂他的人没有否认安装360的用户很多，而是唾弃这种公司能在国内大行其道，劣币驱逐良币

　　你是家里才通网吗? 龙芯早都弃用MIPS了，现在是自研的LoongArch。 自己好好看看吧：

　　不是不让用jni和unsafe啊, 只是做了限制, 只要加命令行参数就能继续用, 目的是为了让使用者考量程序的安全性.

　　评论区很有意思，黑底白字写个kernel panic跟蓝底白字什么差别.还“史诗级退步”好的不学坏的学的挺快

　　为什么一定要强调“国产”？是开源的项目么？如果开源，是不是不接受国外开发者的贡献？我只是好奇，不带“国产”，是宣传不了了么😀

　　开源日报 苹果将更新Mac mini；IntelliJ IDEA 2024.2；AI产业半年报；有CPU就能跑大模型