
本周已经在圣彼得堡举办了
TechTrain IT庆典。 演讲者之一将是Richard Stallman。
Embox也参加了音乐节,我们当然不能忽略开源软件的话题。 因此,我们的一份报告称为
“从学生手工艺品到开源项目。 Embox体验 。
” 作为开源项目,它将致力于Embox的历史。 在本文中,我想谈一谈我认为会影响开源项目开发的主要思想。 该文章与报告一样,都是基于个人经验。
让我们从术语“开源”的简单定义开始。 显然,开源项目是具有许可证之一的项目,该许可证允许您访问该项目的源代码。 此外,一个开放的项目意味着第三方开发人员可能会进行更改。 也就是说,如果某个公司或开发人员部分或完全发布其产品的代码,则这不会使该产品成为开源项目。 最后,任何项目活动都应导致某种结果的出现,而项目的开放性意味着不仅开发人员自己都使用该结果。
我们不会涉及开放许可证的问题。 这个话题太大而又复杂,需要深入研究。 关于这个主题,已经写了很多好的文章和材料。 但是由于我本人不是版权领域的专家,所以我只能说许可应该符合项目的目标。 例如,对于Embox,选择BSD而不是GPL许可证并不是随机的。
开放项目应该可以进行更改并影响开放项目的发展这一事实表明该项目是分布式的。 与具有集中管理的项目相比,对其进行管理,保持完整性和效率要困难得多。 一个合理的问题出现了:为什么根本没有开源项目? 答案在于商业可行性领域;对于某些类型的项目,这种方法的收益大于成本。 也就是说,并非对于所有项目,开放方法通常是可以接受的。 例如,很难想象基于开放原理的发电厂或飞机控制系统的开发。 当然,不值得在这样的系统中包括基于开放项目的模块,因为这将提供许多优势。 但是有人必须回答最终产品。 即使系统完全基于开放源代码,开发人员也将所有内容打包到一个系统中并进行特定的程序集和设置,从而将其关闭。 该代码可能是公开可用的。
对于这些系统,创建开源项目或参与其中也有很多好处。 就像我说的那样,最终系统代码可以保留在公共域中。 为什么,因为很明显,几乎没有人会使用同一架飞机来测试系统。 的确如此,但是很可能有人希望检查代码的各个部分,例如,有人可能会发现所使用的库配置不正确。
如果公司将系统的某些基本部分分配到一个单独的项目中,则将带来更大的收益。 例如,一个支持某种数据交换协议的库。 在这种情况下,即使协议是特定于给定主题领域的,也可以与该领域的其他公司分担维护此系统的费用。 此外,可以在公共领域研究系统的专家所需的时间大大少于有效使用它的时间。 最后,将一块突出显示为第三方开发人员使用的独立实体,可以使这一部分变得更好,因为您需要提供有效的API,制作文档,我什至没有在谈论提高测试范围。
公司可以在不创建开放项目的情况下获得商业利益,这足以使其专家参与公司使用的第三方项目。 毕竟,所有好处仍然存在:员工更了解项目,因此他们可以更有效地使用项目,公司可以影响项目开发的方向,那么,使用现成的调试代码显然可以降低公司的成本。
创建开源项目的好处并不止于此。 让我们将业务的重要组成部分作为营销。 对他来说,这是一个很好的沙箱,可让您有效地评估市场需求。
当然,我们决不能忘记,开源项目是将自己声明为任何专业化载体的有效方法。 在某些情况下,这通常是进入市场的唯一途径。 例如,Embox最初是创建RTOS的项目。 可能无需解释有很多竞争对手。 如果不创建社区,我们将根本没有足够的资源将项目带给最终用户,也就是说,第三方开发人员无法使用该项目。
社区是开源项目的关键。 它使您可以大大降低项目管理成本,开发和支持项目。 可以说,没有社区就根本没有开源项目。
关于如何创建和管理开放源代码项目社区的大量材料已经编写。 为了不重述已有的事实,我将着重于Embox的经验。 例如,一个非常有趣的问题是创建社区的过程。 也就是说,许多人讲述了如何管理现有社区,但是考虑到社区的存在,有时却忽略了社区的创建时刻。
创建社区开源项目时的主要规则-没有规则。 我的意思是,仅由于项目有很大不同,就没有通用规则,就像灵丹妙药。 为js日志记录库和一些高度专业的驱动程序创建社区时,几乎不可能使用相同的规则。 而且,在项目(以及社区)开发的不同阶段,规则也会更改。
Embox最初是一个学生项目,因为系统编程系的学生可以进入。 实际上,我们进入了其他社区。 这个社区的参与者,学生,我们可能会对他们的专业,系统编程领域的科学工作,学期论文和文凭感兴趣的良好工业实践。 也就是说,我们遵守了社区组织的基本规则之一,社区成员必须得到一些东西,并且这个价格应对应于参与者的贡献。
Embox的下一阶段是搜索第三方用户。 了解用户是开源社区的正式成员非常重要。 通常,用户数量多于开发人员。 为了成为该项目的贡献者,他们首先开始以一种或另一种方式使用它。
Embox的第一个用户是理论控制论系。 他们建议为Lego Mindstorm创建替代固件。 尽管仍然是本地用户(我们可以亲自见面并讨论他们想要什么)。 但这仍然是非常好的经历。 例如,我们开发了可以向其他人展示的演示,因为机器人很有趣并且吸引了人们的注意。 结果,我们有了真正的第三方用户,他们开始询问Embox是什么以及如何使用它。
在这个阶段,我们必须考虑文档,以及与用户的沟通方式。 不,当然,我们之前曾考虑过这些重要的事情,但这还为时过早,没有起到积极作用。 效果相当负面。 让我举几个例子。 我们使用了googlecode,该维基的Wiki支持多种语言。 我们制作了几种语言的页面,不仅英语和俄语(沟通能力差),还有德语和西班牙语。 结果,用这些语言询问时看起来很荒谬,但我们根本无法回答。 或者,他们引入了编写文档和注释的规则,但是由于API经常更改且发生了重大变化,因此事实证明,我们的文档已过时,并且误导性超过其帮助范围。
结果,我们所有的努力,甚至是不正确的努力,都导致了外部用户的出现。 甚至出现了一个商业客户,他们希望他开发自己的RTOS。 我们之所以开发它,是因为我们有经验和一些发展。 在这里,您需要谈论优点和缺点。 我将从坏的开始。 由于许多开发人员是在商业基础上参与该项目的,因此社区以及相当不稳定的组织分裂了,这当然会影响该项目的开发。 另一个因素是,该项目的方向是由一个商业客户确定的,其目的不是该项目的进一步开发。 至少这个目标不是主要目标。
另一方面,有很多积极点。 我们真的有第三方用户。 不仅是客户,而且是该系统的目标客户。 参与该项目的动机有所增加。 毕竟,如果您还可以在一件有趣的事情上赚钱,那总是很好。 最重要的是,我们听到了客户的一种愿望,这在当时对我们来说是疯狂的,但是现在这是Embox的主要思想,即使用系统中已经开发的代码。 Embox的主要思想是使用不带Linux的Linux软件。 也就是说,促成项目进一步发展的主要积极因素是意识到该项目已被第三方用户使用,并且应该解决他们的一些问题。
那时,Embox已经超出了学生项目的范围。 根据学生模型,项目开发的主要制约因素是参与者的动力。 学生们在学习时会参与其中,而当他们毕业时,应该会出现不同的动机。 如果没有动力出现,学生只会停止参加该项目。 如果考虑到必须首先对学生进行培训,那么事实证明他们在毕业时已成为优秀的专家,但是由于经验不足,对项目的贡献不是很大。
总的来说,我们正在顺利地走到重点,这使我们可以谈论创建开源项目-创建可以解决其用户问题的产品。 如前所述,开源项目的主要属性是社区。 此外,社区成员主要是用户。 但是它们从何而来呢? 因此,事实证明,就像非开源项目一样,您需要专注于创建MVP(最小可行产品),并且如果它使用户感兴趣,那么社区将出现在该项目周围。 如果您仅通过社区PR参与创建社区,使用世界上所有语言编写Wiki或在github上使用适当的git工作流程,那么在项目的早期阶段就不太重要了。 当然,在适当的阶段,这些不仅重要,而且是必要的事情。
最后,我想
发表评论 ,以反映用户对开源项目的期望:
我认真考虑过要切换到该操作系统(至少尝试一下。他们非常乐于看到它并做一些有趣的事情)。
PS在
TechTrain,我们将提供多达三份报告。 一种是关于开源的,另一种是关于嵌入式的(另一种是实用的)。 在展台上,我们将主持使用
Embox进行微控制器编程的大师班。 传统上,我们将带腺体并让它们编程。 还将进行一项探索和其他活动。 来参加音乐节和我们的摊位,这将很有趣。