她偏爱雏菊一样的淡黄色

by Filip Hracek

由Filip Hracek

为什么开源项目(非常)偏爱新用户，以及您可以采取什么措施 (Why open source projects (sadly) favor new users, and what you can do about it)

Every now and then, all developer products (SDKs, frameworks, APIs) will have to choose between favoring their existing users or new ones. Make the initial app “just work” for beginners with some default magic? You hurt the debuggability of large apps. Introduce a feature for your power-users? The newcomers will have to deal with a steeper learning curve.

时不时地，所有开发人员产品(SDK，框架，API)都必须在青睐现有用户或新用户之间做出选择。 使用一些默认的魔法使初学者的应用程序“适合工作”吗？ 您损害了大型应用程序的可调试性。 为您的高级用户介绍一项功能？ 新来者将不得不应对更陡峭的学习曲线。

In April, I wrote about the “Hello World” fallacy. This is the unconscious assumption that if it’s easier to get started with technology A than with technology B, then A is better than B.

4月，我写了关于“ Hello World”谬论的文章 。 这是一个无意识的假设，即如果开始使用技术A比开始使用技术B更容易，那么A比B更好。

This is bad, because most developers, most of the time, don’t write hello world apps. They fall in love with how easy it is to build a demo. Then, months later, they struggle while trying to build an actual product.

这很糟糕，因为大多数开发人员在大多数时候都不编写hello world应用程序。 他们爱上了构建演示的难易程度。 然后，几个月后，他们在尝试构建实际产品时遇到了困难。

But it gets worse.

但情况变得更糟。

It’s not just perception. Favoring the “Hello World” scenario actually pays off in the long run if you’re building an open source library or framework. Sadly, you’re better off sacrificing productivity of your long-term users to make things easier for your new users.

不只是感知。 从长远来看 ，支持“ Hello World”场景实际上是有回报的 如果您要构建一个开源库或框架。 可悲的是，您最好不牺牲长期用户的工作效率，从而使新用户更轻松地工作。

This is because of the dynamics of technology adoption:

这是由于技术采用的动态：

There is a reinforcing feedback loop here. The more people try the technology, the more buzz is generated around it, so more people try it, and so on.

这里有一个加强的反馈回路 。 尝试该技术的人越多，围绕它产生的嗡嗡声就越多，因此尝试它的人就越多，依此类推。

After some time, developers stop using the technology and move on to something else. This churn is proportionate to their dissatisfaction with the tech and with its age.

一段时间后，开发人员停止使用该技术，然后继续开发其他产品。 这种流失与他们对技术及其时代的不满成正比。

The problem is with delays. The reinforcing feedback loop from new users is almost immediate. The first blogposts start appearing after mere weeks. But the churn and the more informed articles appear much later, after many months. It takes time to build something real. You need to build something real before you can talk about the underlying technology in an informed way.

问题在于延误 。 来自新用户的强化反馈循环几乎是立即的。 短短几周后，第一批博客文章开始出现。 但是，经过数月之后，客户流失和更明智的文章出现了很多。 构建真实的东西需要时间。 您需要先构建真实的东西，然后才能以明智的方式谈论基础技术。

Let’s say technology A optimized for initial ease of use (“hello world” and small apps). Technology B optimized for long-term users (real apps). If technology A gets twice the initial buzz from new users than technology B, and technology B gets twice the informed buzz than technology A, then technology A still wins — by a large margin. That’s because, in our little model, the informed buzz trails the initial buzz by an average of 12 weeks. That’s all it takes. Technology A will attract new users at a much faster pace. It will also lose users more rapidly than technology B. But that churn happens much later and, in general, slower than in the adoption phase.

假设技术A已针对最初的易用性进行了优化(“ hello world”和小型应用程序)。 技术B针对长期用户(真实应用)进行了优化。 如果技术A从新用户那里获得的初始嗡嗡声是技术B的两倍，并且技术B得到的知觉嗡嗡声是技术A的两倍，那么技术A仍然会赢得胜利-很大。 这是因为，在我们的小模型中，明智的蜂鸣声比初始蜂鸣声平均落后12周。 这就是全部。 技术A将以更快的速度吸引新用户。 与技术B相比，它还会使用户流失更快。但是，这种流失发生的时间要晚得多，而且通常比采用阶段要慢。

By the time technology A loses its advantage, it’s all over. Both technologies are on their slow way out. Technology A had been used by almost twice as many developers at that point. Despite being worse for building real apps.

当技术A失去优势时，一切都结束了。 两种技术都在缓慢发展中。 那时，技术A的使用量几乎是开发人员的两倍。 尽管构建真正的应用程序更糟 。

Say technology B goes all the way. It optimizes the hell out of the long-term user experience, and completely de-prioritizes the “hello world” scenario. The result is even sadder:

说技术B一路走来。 它从长期的用户体验中优化了地狱，并完全取消了“ hello world”方案的优先级。 结果更令人难过：

No matter how you fiddle with the numbers, technology B always loses. The reinforcing feedback loop and the delay in churn will always be there.

无论您如何摆弄数字，技术B总是会失败。 不断增强的反馈回路和搅动延迟将始终存在。

Let’s look at exactly what I mean by “optimizing for new users” versus “optimizing for long-term users.”

让我们看看“优化新用户”与“优化长期用户”到底是什么意思。

对于新用户(头几周或几个月)重要的是： (What’s important for new users (first few weeks or months):)

• Length and ease of first-time setup首次安装的时间和简便性
• Defaults & automagic (ability to “just work” for the most prevalent initial scenarios)默认值和自动值(在最普遍的初始方案中“正常工作”的能力)
• Size of small apps小型应用程式的大小
• Performance of small apps小型应用的性能
• Freedom (“use whatever you’re used to”)自由(“使用您习惯的方式”)

对于长期用户来说重要的是(一旦他们构建了一个大型应用程序)： (What’s important for long-term users (once they’ve built a large app):)

• Ease of refactoring易于重构
• Explicitness (the “do not surprise the programmer” principle)显式(“不要让程序员感到惊讶”的原则)
• Customizability可定制性
• Size of big apps大应用程式的大小
• Performance of big apps大应用程序的性能
• Standardization标准化

为什么这是开源问题？ (Why is this an open source problem?)

One great thing about open source is that it’s free. In this case, that’s also part of the problem.

开源的一大优点是它是免费的。 在这种情况下，这也是问题的一部分。

Paid SDKs and frameworks will never see the rate of adoption that open source does. But they’re also someone’s business. Businesses tend to prefer ongoing, long-term customers over uncertain new leads. If technology A was a company, it would not fare well.

付费的SDK和框架永远不会看到开源的采用率。 但是他们也是某人的事。 与不确定的新潜在客户相比，企业往往更喜欢长期的长期客户。 如果技术A是一家公司，那将不会很好。

Please note: I am not saying we should all start paying for frameworks now. I’m just explaining why open source is particularly vulnerable to this problem.

请注意：我并不是说我们现在都应该开始为框架付费。 我只是在解释为什么开源特别容易受到这个问题的影响。

I believe this is one of the reasons for the “JavaScript fatigue” in the web world, by the way. That ecosystem naturally selects technologies that are easy to start with. This creates an arms race: new generations of libraries and frameworks are ever more easy on the newcomer, but harder to scale.

顺便说一下，我相信这是网络世界中“ JavaScript疲劳 ”的原因之一。 该生态系统自然会选择易于入门的技术。 这将引发一场军备竞赛：新一代的库和框架在新用户面前更加容易，但扩展规模却更大。

Technologies that don’t optimize for the “hello world” are doomed to obscurity. You end up with a rapid succession of technologies that are innovative but not great for building large software projects.

无法针对“ hello world”进行优化的技术注定会变得晦涩难懂。 您最终将获得一系列快速创新的技术，但这些技术对于构建大型软件项目并不理想。

It’s not only the JavaScript ecosystem, of course. The whole world of developer products is seeing faster turnarounds. The .NET Framework is 15 years old this year, and it’s still in use. That’s a remnant of an old era. Today, even outside the web ecosystem, we see frameworks that ‘rule’ for 18 months and then die.

当然，不仅是JavaScript生态系统。 整个开发人员产品世界的周转速度更快。 .NET Framework今年已有15年历史，并且仍在使用中。 那是一个旧时代的残余。 今天，即使在网络生态系统之外，我们也看到了“统治”了18个月然后消失的框架。

我们对于它可以做些什么呢？ (What can we do about it?)

I hope I’ve shown that this is not about framework and library owners being dishonest, nearsighted, or stupid. The problem is inherent to the ecosystem. It stems from feedback delays — something nobody can really do anything about (unless they possess a time machine).

我希望我已经证明这不是关于框架和库所有者是不诚实，近视或愚蠢的。 这个问题是生态系统固有的。 它源于反馈延迟-没人真正能做任何事情(除非他们拥有时间机器)。

As a library owner, if you “choose not to play,” you will significantly harm your project’s chances for success. You will become technology B.

作为图书馆的所有者，如果您“选择不参加比赛”，将大大损害您项目的成功机会。 您将成为技术B。

That being said, framework owners can be conscious about this. They can educate about software scalability. They can seek out their largest “customers” and work closely with them. They can consciously and transparently emphasize large apps over tech demos. My hope is that the industry starts doing it as a whole. It’s in everyone’s interest.

话虽如此，框架所有者可以意识到这一点。 他们可以教育软件可伸缩性。 他们可以寻找最大的“客户”并与他们紧密合作。 他们可以有意识地透明地强调大型应用程序，而不是技术演示。 我的希望是整个行业都开始这样做。 这符合所有人的利益。

For consumers of these frameworks (and SDKs, libraries, APIs), the advice is quite simple:

对于这些框架(以及SDK，库，API)的使用者，建议非常简单：

Never listen to anyone who hasn’t built a very large* app with the technology they’re talking about.

永远不要听任何没有使用他们正在谈论的技术构建大型应用程序的人。

(* The size of the app depends on what you want to build.)

(*应用程序的大小取决于您要构建的内容。)

The problem with this piece of advice is probably clear. If you live by it, you’ll miss every cool new technology that is out there. By the time someone builds something big enough, and is therefore competent to speak, you might very well be too late to the party.

这条建议的问题可能很明显。 如果您靠它生活，您将错过那里提供的每项炫酷新技术。 到有人建立足够大的东西并因此有发言权的时候，您可能对党来说已经太迟了。

So I have some less glorious but more practical advice for you:

因此，我为您提供了一些不太光荣但更实用的建议：

• Take note of the people on the project and their track record. Past behavior is the best predictor of future behavior.

  注意项目上的人员及其往绩。 过去的行为是未来行为的最好预测。

• Ignore the “hello world” experience. Know that 99.99% of your time with the technology will not be “hello world.”

  忽略“ hello world”的体验。 知道使用这项技术的99.99％的时间不会是“ hello world”。

• Be wary of implicit “magic.” That almost never mixes well with real apps.

  警惕隐含的“魔术”。 这几乎无法与真实应用完美融合。

• Discount recommendations by people who only build small apps or proof-of-concepts.

  仅构建小型应用程序或概念证明的人的折扣建议。

• If you want to get fancy, build “app generators” that automatically produce very large codebases in the technologies you are evaluating. With this, you can produce an approximation of a huge 100KLOC app in a single afternoon. See how the generated large app performs and how the tooling keeps up at this scale. (This is what the AngularDart team at Google does to gauge its own framework’s standing among others.)

  如果您想花哨的话，请构建“应用程序生成器”，以使用您正在评估的技术自动生成非常大的代码库。 有了这个，您可以在一个下午内近似生成一个巨大的100KLOC应用程序。 查看生成的大型应用程序如何执行以及工具如何保持这种规模。 (这是Google的AngularDart团队用来衡量自己的框架在其他领域的地位的做法。)

If you have other ideas, please share them in the comments. I’ll happily add the best ones above.

如果您还有其他想法，请在评论中分享。 我会很高兴在上面添加最好的。

翻译自: https://www.freecodecamp.org/news/why-open-source-projects-sadly-favor-new-users-and-what-you-can-do-about-it-ba586038949e/

她偏爱雏菊一样的淡黄色