如何创建开源项目

如何创建开源项目本周圣彼得堡将举办 IT 节 TechTrain。 理查德·斯托曼 (Richard Stallman) 是演讲者之一。 信箱 同样参加这个节日,当然也不能忽视自由软件的话题。 这就是为什么我们的一份报告被称为 “从学生工艺品到开源项目。 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 工作流程,那么这在项目的早期阶段不太可能重要。 当然,在适当的阶段这些不仅是重要的,而且是必要的。

最后我想指出 一条评论在我看来,反映了用户对开源项目的期望:

我正在认真考虑切换到这个操作系统(至少尝试一下。他们正在积极追求它并做很酷的事情)。

电源打开 TechTrain 我们将收到多达三份报告。 一篇关于开源,两篇关于嵌入式(其中一篇是实用的)。 在展台上,我们将举办一个关于使用微控制器编程的大师班 信箱。 像往常一样,我们会带来硬件并让您对其进行编程。 还会有任务和其他活动。 来到节日和我们的展位,一定会很有趣。

来源: habr.com

添加评论