开源

如何维护一个开源项目

之前跟大家聊了很多如何参与一个开源项目,今天跟大家聊聊如何维护一个开源项目。

开源项目并不是代码的集合:每一个开源项目都能够视作一个小型的公司,它有自己的市场定位,有自己的战略目标,有自己的用户受众。因此开源项目维护有着大量工程以外的工作,包括但不限于跟用户沟通,设定路线图等等。本文旨在为加入开源维护者行列的新人提供一个基本的指引,讲解开源维护者应该需要做的事情。

First Day

开源维护者在开始一个项目之前,需要首先搞清楚项目的目标市场及其定位。

明确市场

开源项目的发展也大体遵循着强者恒强的马太定律:一个特定的垂直领域往往只能容下一到两个广泛使用的项目。

所以在开始一个项目之前我们就必须考虑清楚:

  • 项目想要哪个领域发展?
  • 这个领域都有哪些重要玩家?
  • 我们项目有哪些不可替代的优势?

如果我们不能够比现有项目做的更好,不如直接放弃加入现有项目。否则我们就需要进一步对领域进行细分,找到自己的差异化优势。

比如最近 SmartX 发起了一个新的开源项目 virtink,一个更轻量的 Kubernetes 原生虚拟化管理引擎。相比于社区现有的 kubevirt,它不考虑支持遗留硬件设备的模拟以及桌面应用场景能力,而是聚焦于在 Kubernetes 上运行现代化的云端虚拟化负载,因此 Virtink 就可以做到以更安全轻量的方式支撑虚拟化负载。

当然目前市场并不是一成不变的:字节跳动开源的 monoio 最开始市场是基于 io-uring 的 thread-per-core 模型高性能 Rust Runtime,但是在社区的演进中逐渐加入了对 tokio mio 的支持。

开源项目的维护者需要审慎地考虑项目的发展来选择是否加入或者进入某个领域。

立下愿景

文章合为时而著,代码合为事而写。开源项目必须要能够解决实际的问题,否则就无法形成一个可靠的开源共同体。

如何正确使用别人的开源代码?

为什么要写这个?

我之所以写这个话题,是因为最近我看到有些人在他们的项目中使用我的代码而没有保留版权声明(我真的不想在本文中怪任何人)。
他们使用我的代码并不是真正的问题,我喜欢鼓舞其他人根据我的一些概念和想法做一些很棒的事情,并且很高兴能为您提供代码帮助。因此,每个人都可以自由使用我的代码,但是根据给定的许可条款,现在是重要的部分。您也可以说“credit where credits needed”。在软件环境中开源并不意味着您可以复制漂亮的东西并将其粘贴到您的项目中,并告诉所有人您做得很好。那不是它的工作方式,因为原始作者会生气,而当作者感到生气时,他很可能不再发布出色的开源软件,或者至少他不会发布。可以这样考虑:我使用了另一位开发人员的出色代码,这位开发人员投入了大量时间来编写这段出色的代码,至少我可以赞扬编码人员,以展示自己的才能。感谢。我也在写它,是因为我经常看到它,没人在乎许可证。
本文应该是有关软件获得许可并要使用它时的确切摘要。我挑选了最常见的OS(开源)许可证,因为那里有很多许可证,请随时查看所有许可证。您下次可以将本文用作指导;-)我对完整性不承担任何责任,如果您认为我忘记了什么,请告诉我!…

        

如何为开源PHP软件包做贡献

介绍

鉴于即将举行的Hacktoberfest,我想为初学者分享一些技巧,这些初学者可能想专门为PHP 软件包做出第一笔贡献。从我自己的经验来看,与“常规”(Laravel)应用程序相比,在一个程序包上工作可能看起来很艰巨。

这篇文章旨在为初学者贡献一些开源PHP软件包的指导。…

        

开源维护者的心理建设

最近知名 Rust 框架 actix-web 的作者宣布不再做开源,在 Rust 社区内外都引发了不少关注。我个人并不使用 Rust,但同为开源维护者,对于这件事有很多感同身受的地方。我对于事情的孰是孰非不想多做评论,对前因后果感兴趣的读者可以自行搜索,这里主要借这个事件谈谈独立开源维护者的心理建设问题。

大部分开发者开始做独立开源(非公司项目)的时候,都是出于很单纯的动机:我写了一个很有用/有意思/没人做过的东西,分享出来给大家看看,要是有人点几个 star 那就美滋滋了。一些负责维护公司项目的同学可能也因为对项目投入了很多,对于项目有着超乎工作责任之外的感情。这些项目里有一部分会获得超出作者预期的增长,然而随之而来的也是超出预期的维护责任:突然你发现自己每天要面对一堆只增不减的 issue,千奇百怪的用户需求,处理不完的用户提问,人们开始拿你的项目跟其他项目比来比去,对你的代码甚至是言论指指点点,甚至为此撕逼... 你工作外的时间基本上都给了开源,然而与此同时,你的项目并没有给你带来什么除了自豪感之外的实质利益,你慢慢开始怀疑自己到底值不值得继续为这个项目投入这么多精力。有时候你觉得,支撑你继续下去的唯一动力仅仅是不敢面对辜负社区的罪恶感...…

有赞开源项目最佳实践

因为业务需求,有赞自己造了很多轮子,组件库尤其多,React,Vue,小程序都有涉及,其他开源项目有 zan-proxy 代理,PHP 的框架 zanphp 等。有人可能会觉得奇怪,为什么有赞要造这么多轮子?其实原因真的很简单,就是因为现有的替代品无法满足我们自身业务的需求,可能是不满足我们的定制需求,也可能是功能不符合我们要求。根据业务需要,我们总结了一套适合自己的套路、规范,并把这些套路、规范做成了工具、组件库或者框架。

这大概便是有赞内部启动这些项目的缘由了。后来,随着这些项目的逐步完善,一个自然而然的想法就是把它们开源了,也许别人也有类似我们的需求。

慢慢的,有赞的 Github 上就有了好多开源项目。在维护这些开源项目的过程中我们总结了一些经验教训,在此跟大家分享。

一、有赞的 Github 使用姿势

Github 有一定的社交属性,维护好一个开源项目除了代码写得好,有一些使用姿势也是很重要的,我们总结了几点跟大家分享。

1. 一个好的 README 很重要

README 文件是项目给人的第一印象,所谓人靠衣装马靠鞍,开源项目有个好的脸面是很重要的,尤其是当这个项目还是一个前端项目的时候。针对 README 文件我们给出以下几点建议:

  • 同一个组织的 README 统一格式
  • 最好有个英文版的 README
  • 加上开发指南的链接

统一 README 格式的好处是让别人一眼就认出这个项目是某某公司或者某某人的,有赞内部就维护了一份 README 的规范。模版内容很简单,但是它保证了我们的项目有一定的识别度。

youzan-readme

英文版的 README 不是为了装逼,如果你笃定自己的用户都在国内,那就只需要中文版的 README

    

如何实施开源协议,以及如何遵守开源协议的要求

网上有很多开源协议的介绍,但是很少有说明如何在你自己开发的软件中使用开源协议,保护自己的代码;以及当你使用别人开源项目时,如何遵守开源协议里面约定的行为。文本从github上找了些项目举例描述下这2个问题。至于各个协议的具体说明网上一搜一大堆,本文不再描述。…

    

如何为你的开源项目选择一个合适的开源协议?

今天又看到一个同学发布维权帖子《开源 App 被人抄袭到 iOS App Store 怎么办?》这个帖子转发到技术群的时候引发了很大的讨论,大多数同学都是声援的态度,也有较真的同学在讨论 MIT License ,那么License 是什么,MIT License 又是什么?

License就是版权许可证,里面详尽表述了你获得代码后拥有的权利,可以对别人的作品进行何种操作,何种操作又是被禁止的。软件的版权许可证可有很多方式 ,本文仅限于讨论开源软件协议 Open Source License。…

开源中最好的Web开发资源汇总

法国Web开发人员 Julien Guézennec 整理汇总的有关Web开发的资源和目录,由陈皓翻译。

学习HTML 5编程和设计