开源代码指南?

发布于 2024-09-03 01:00:41 字数 1435 浏览 2 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

允世 2024-09-10 01:00:41

我会考虑以下几点:

  • 清楚地考虑开源软件的目标,并据此检查您的所有决定。
  • 仔细检查所用库的所有许可证是否与所选许可证兼容,并且您有权使用代码库中的任何内容。这还包括图像或其他非代码。如果来源是全世界可见的,那么版权侵权就很容易被发现,您的竞争对手可能会利用这个机会给您带来麻烦。
  • 选择合适的许可证。最重要的决定可能是 Copyleft(GPL、AGPL)或不是(Apache、BSD、MIT)。
  • 再次检查您的代码并删除您不想在公众中看到的任何内容(愚蠢的评论等)。
  • 编写文档以从源代码构建软件。如果您有一个好的构建文件,它可能像“make”一样简单,但很可能您必须记录有关依赖项(例如已安装的库等)的信息。
  • 提供某种方式联系您的公司以了解该软件。也许是一个电子邮件地址和一个回复该电子邮件的人。
  • 如果您想吸引外部编码人员,请记录源代码的一些重要部分。提供一些有关结构的基本文档,外部开发人员可以弄清楚他们应该编辑哪个源文件,以更改软件的行为 X。
  • 如果您想与外部程序员合作,您将需要一个世界可读的版本控制。如果您获得的补丁对于您的实际代码库来说已经过时,那么它没有任何帮助。如果您有人经常发送补丁,请给予他们提交权。开放的错误跟踪器也很有用。如果您不想在公司自行托管这两个工具,请使用 Open-源托管站点
  • 如果您选择 Copyleft 许可证,请让所有外部提交者签署合同,以允许您使用他们的添加内容。否则您将无法在您公司的其他专有产品中使用这些更改。

就是这样,我此刻想到的就是这个。

I would consider the following:

  • Think clearly about the goals of open-sourcing your software and check all your decisions in this light.
  • Double check, if all licences of used libraries are compatible with the chosen license and you have the permission to use anything in the codebase. This also includes images or other non-code. If the source is world-visible, copyright-infringements are easy to spot, and your competitors might use the chance to make you trouble.
  • Choose an appropriate license. Most important decision might be copyleft (GPL, AGPL) or not (Apache, BSD, MIT).
  • Check your code again and remove anything, that you don't want to see in the public (silly comments or so).
  • Write a documentation to build the software from the source. If you have a good buildfile that could be as easy as 'make', but most likely you have to document about dependencies like installed libraries and so on.
  • Provide some way to contact your company about the software. maybe an e-mail-address and a someone, who answers to this e-mail.
  • If you want to attract external coders, document some important parts of the sourcecode. Provide some basic documentation about the structure, that external developers can figure out, which source-file they should edit, to change behaviour X of the software.
  • If you want to work with external programmers, you will need an world-readable Version-control. If you get patches, that are outdated against your actual codebase, it isn't helpful. If you have persons, who often send patches, give them commit-rights. Also an open bug-tracker is useful. If you don't want to host the two tools yourself at your company, use an Open-Source Hosting site.
  • If you choose a copyleft-license, let all external committers sign a contract, that give you permission to use their additions. Otherwise you couldn't use the changes in other propietary products of your company.

That's it, what comes to my mind at the moment.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文