10年的开源

2011年6月4日，我发布了一款我从DataMapper项目中提取的Ruby Gem的第一个版本。

我记得我如何感受到开源的回归，而且我必须告诉你我的观点变化了很多。

10年来，十年令人震惊的十年，是很多时间＆amp; Mldri在那个时候经历了很多起伏，因为我的开源贡献天空飙升，而改变的观点是我不断考虑的东西。我不知道我贡献了多少个项目，我写了多少个图书馆，我真的不知道。

这个10年周年纪念日让我超级情感，我对我想分享的开源有很多想法。

这将是苦涩的，可能太长了。请记住，这是基于我自己的经验，我会尽力不要概括太多。

我记得在20多岁的20多岁时，当我已经作为一个软件开发人员工作时，我在我的脑海里有这个概念，开源是每个人都在做的惊人的事情。也许它听起来很荒谬，但这正是我曾经看到的那样。我是一个沉重的思想家和一个自然的问题 - 解决者，最重要的是，我非常不耐烦。

这是一个完美的混合，成为一个开源的贡献者，因为每当有东西对我不起作用时，我要么在稍后一次工作，或者我已经通过原型设计了我自己的解决方案。

这正是我最终为DataMapper结束的方式，然后加入核心团队，然后释放Virtus，然后在DataMapper 2.0上工作，然后将其转换为ROM-RB，然后加入Dry-RB并平均建设1.25库/月2年左右最终加入Hanami Team＆amp; Mldrand，是的，当我回头看时，现在已经有点坚果了。

在大多数情况下，我认为“这是每个人都做的”，直到我意识到这绝对不是这种情况。

击中我的第一件事是需要“只是”以维持图书馆的工作量。即使您有一个使用的库，让我们说，27人（相对较低的数字），这可以很容易地每月转化为10个小时的工作，每月都有10个小时的工作。如果您有多个图书馆，并且使用您的东西的人数现在计算在数百甚至数千人，这可以很容易地失控。在各种项目中显然会停机，特别是更成熟的项目 - 但平均一旦维护某些东西，它就会变得超级难以找到你实际要做的工作的时间。

你显然负责管理你的时间和你所做的事情，我们可以轻松地说“好吧，没有人迫使你在OSS上工作”并结束讨论和amp; mldrbut是简单的吗？

人们认为开放来源只是这一大，全球家庭。成千上万的人致力于所有这些惊人的图书馆，框架和工具。这是绝对，清楚地看到的开源的理想主义观点。我觉得这几天变得有点改变，但它仍然存在。

我一直遇见几乎道似乎的人告诉我他们希望他们贡献更多。

我的问题是：这里的交易是什么？是什么让我们认为我们有义务这样做？

我看到的方式是我们已经为自己创造了自己的印象。我们一直告诉我们，我们需要构建开源软件，因为它是软件的未来（它是！）。我们也保持令人信服，这就是你如何成为一个更好的开发人员（你可以！），所以有些人只是在更努力的工作时翻了一番。

然后你有公司及其期望。它曾经是 - 并且可能仍然是 - 很常见的是，看到作业优惠的那些被提到“贡献”的“很好”或甚至要求。我认为现在这是一个糟糕的练习，除了工作确实涉及贡献OSS的情况。

我相信为您提供额外支持OSS工作的公司对OSS的这一概念贡献了我们应该做的事情。

但是，这个问题仍然没有答案。这是什么交易？我觉得我们都可以尝试提出自己的答案，这将在个人水平上为我们工作。尽管如此，很难提出普遍的答案。

当您使用产品和客户使用您的产品时，您正在支付您的产品，那么这笔交易很简单 - 您正在处理他们所需要的，并且他们为您支付给您。但是，当涉及开源时，这极其复杂和模糊。什么是产品？谁是客户？我们甚至可以像那样对待一个开源项目吗？或者也许这笔交易是没有交易，这是它的美丽？

如果你是一个维护者，那么这可能会响起一些铃声。如果你没有，你正在使用OS，那么这可能很有用。

让我们真实 - 我们不是一个大，全球，家庭。大多数工作是通过全球开发人口的一小部分完成的。我们喜欢认为我们都在一起，但我们不是。

您可以欣赏巨大的统计数据，表明成千上万的人正在为OSS项目做出贡献 - 但实际上实际上工作，在建立核心功能，测试，修复错误，制作性能改进，支持用户的无数小时，编写文档，响应问题，处理拉维要求等由维护者完成。

让我也非常清楚：所有贡献计数，它们都很重要，非常感谢。

但我的观点是强调，当1000人每次做一点工作时，你总共获得了重大结果，但请意识到每个人都花在他们的贡献中的时间不能比较维护者花在的时间他们的工作。

为了说明情境的类型，维护人员必须定期处理，这是一些现实世界场景：

你从某人那里得到一个错误报告。你花了3个小时调试并带着补丁来了。您要求用户测试。用户永远不会回复你。

您收到一个功能请求。你花了几个小时讨论它。您正在经历源代码，弄清楚如何实现它。你最终有一个很好的poc。你问用户如果它会很好。用户永远不会回复你。

你得到一个拉扯请求。您审核它，它看起来很好，但您留下了一些评论，因为必须解决几件小事。用户永远不会回复你。

你可以用愤怒的用户试图指出你的错误。你尽最大愉快，但用户不断攻击你。你总共花几个小时只是为了讨论它。您达到了一些级别的共识，然后猜测，用户永远不会回复您。

有人在一年前报道了这个问题，你想最终解决它，但你找不到时间/能源/动机/等等。去做吧。它被标记为“帮助想要”，但人们一直用评论“这是关于此处的任何进展”即使它甚至不是你的工作，甚至没有你的工作，内疚感的不舒服感开始。

这是一个想法的东西：没有人有时间在开源上工作。没有人。没有时间，但我们以某种方式做到这一点。这些情况中的许多情况是由用户没有足够的时间的事实引起的。在其他情况下，它是没有足够时间的维护者。我们努力推动事情前进，往往非常不生产。

它非常诱人地说，现在我们拥有所有这些平台，其中可以在经济上支持开源维护者，因此解决问题。不幸的是，事情并不那么简单。

首先，我相信赞助的开源工作仍然是一个难以说这笔交易的情况。如果您的项目足够受欢迎，更不用说你只能成功获得赞助。

我认为在OSS中，这是在较低级别的库中做出非常重要的工作，但这是不可明显的工作类型，这是一个更加明显的，顶级的项目＆amp; mldr的工作提到你首先需要一个项目，只是这已经是一个大的时间投资。假设您确实做到了，你现在有一个OSS项目被大量的人使用，你仍然需要投入大量时间才能建立你的存在。

这很重要 - 没有人会发现你只是因为你在GitHub上发表了一个项目。这是苛刻的现实，但我认为这是真的。

您不能假设每个OSS维护者愿意做赞助所需的工作类型。

尽管我欣赏Github赞助商，但我仍然认为应该有一个更积极的转变向企业的赞助，而不是个人。许多人与我分享了一篇文章从一个戒掉他的日常工作的开源开发商，现在通过GitHub赞助来制作更多。当我阅读本文时，我的第一个想法是“哇这是如此令人敬畏”，但我很快就意识到了这实际上的努力。

这位开发人员显然擅长他的比赛。他可以告诉他是一个自然的通讯员和营销人员。现在想想有多少人，现实地说话，能够做到他所做的事吗？我相信不是那么多。考虑英语不是他们的第一语言的人。即使是这种常见的“限制”也让赞助商挑战 - 因为你需要一个令人信服的，在你的着陆页上写得很好地写入介绍，而且母语的英语扬声器很可能会做得更好。

我非常感谢我的个人支持者，但我公开说我不相信这就是它应该如何工作。我希望支持我的人真正受益于我的工作，但同时它是我的图书馆的疯狂，即Netflix或Apple，但他们不是我的赞助商。这就是我希望看到改变的东西。

赞助OSS工作的公司数量应该大于支持OSS工作的个人数量。我不知道现在的数字是什么，看到一些统计数据真的很有趣。

我知道有许多公司赞助的人，我知道一些公司将OSS开发人员雇用为全职员工。这很棒，我希望它会在某些时候成为常态。现在看起来我们要经历一些过渡阶段，我实际上真的很乐观。

在一个非常个人的层面 - 我要感谢Ruby社区的所有人和所有帮助我成长的人，他们激发了我，谁通过困难时期支持我。谢谢你的信任，并为我带来这么长的♥

我知道这篇文章是苦涩的甜蜜，但总体而言，我其实想说的是我非常感激。 我学到了这么多，我相信我会更多地学习更多。 评论由Disqus提供动力