她偏愛雛菊一樣的淡黃色

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.

時不時地，所有開發(fā)人員產(chǎn)品(SDK，框架，API)都必須在青睞現(xiàn)有用戶或新用戶之間做出選擇。 使用一些默認的魔法使初學者的應(yīng)用程序“適合工作”嗎？ 您損害了大型應(yīng)用程序的可調(diào)試性。 為您的高級用戶介紹一項功能？ 新來者將不得不應(yīng)對更陡峭的學習曲線。

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月，我寫了關(guān)于“ Hello World”謬論的文章 。 這是一個無意識的假設(shè)，即如果開始使用技術(shù)A比開始使用技術(shù)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.

這很糟糕，因為大多數(shù)開發(fā)人員在大多數(shù)時候都不編寫hello world應(yīng)用程序。 他們愛上了構(gòu)建演示的難易程度。 然后，幾個月后，他們在嘗試構(gòu)建實際產(chǎn)品時遇到了困難。

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”場景實際上是有回報的 如果您要構(gòu)建一個開源庫或框架。 可悲的是，您最好不犧牲長期用戶的工作效率，從而使新用戶更輕松地工作。

This is because of the dynamics of technology adoption:

這是由于技術(shù)采用的動態(tài)：

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.

這里有一個加強的反饋回路 。 嘗試該技術(shù)的人越多，圍繞它產(chǎn)生的嗡嗡聲就越多，因此嘗試它的人就越多，依此類推。

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.

一段時間后，開發(fā)人員停止使用該技術(shù)，然后繼續(xù)開發(fā)其他產(chǎn)品。 這種流失與他們對技術(shù)及其時代的不滿成正比。

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.

問題在于延誤 。 來自新用戶的強化反饋循環(huán)幾乎是立即的。 短短幾周后，第一批博客文章開始出現(xiàn)。 但是，經(jīng)過數(shù)月之后，客戶流失和更明智的文章出現(xiàn)了很多。 構(gòu)建真實的東西需要時間。 您需要先構(gòu)建真實的東西，然后才能以明智的方式談?wù)摶A(chǔ)技術(shù)。

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.

假設(shè)技術(shù)A已針對最初的易用性進行了優(yōu)化(“ hello world”和小型應(yīng)用程序)。 技術(shù)B針對長期用戶(真實應(yīng)用)進行了優(yōu)化。 如果技術(shù)A從新用戶那里獲得的初始嗡嗡聲是技術(shù)B的兩倍，并且技術(shù)B得到的知覺嗡嗡聲是技術(shù)A的兩倍，那么技術(shù)A仍然會贏得勝利-很大。 這是因為，在我們的小模型中，明智的蜂鳴聲比初始蜂鳴聲平均落后12周。 這就是全部。 技術(shù)A將以更快的速度吸引新用戶。 與技術(shù)B相比，它還會使用戶流失更快。但是，這種流失發(fā)生的時間要晚得多，而且通常比采用階段要慢。

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.

當技術(shù)A失去優(yōu)勢時，一切都結(jié)束了。 兩種技術(shù)都在緩慢發(fā)展中。 那時，技術(shù)A的使用量幾乎是開發(fā)人員的兩倍。 盡管構(gòu)建真正的應(yīng)用程序更糟 。

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:

說技術(shù)B一路走來。 它從長期的用戶體驗中優(yōu)化了地獄，并完全取消了“ hello world”方案的優(yōu)先級。 結(jié)果更令人難過：

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.

無論您如何擺弄數(shù)字，技術(shù)B總是會失敗。 不斷增強的反饋回路和攪動延遲將始終存在。

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

讓我們看看“優(yōu)化新用戶”與“優(yōu)化長期用戶”到底是什么意思。

對于新用戶(頭幾周或幾個月)重要的是： (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
  小型應(yīng)用程式的大小
• Performance of small apps
  小型應(yīng)用的性能
• Freedom (“use whatever you’re used to”)
  自由(“使用您習慣的方式”)

對于長期用戶來說重要的是(一旦他們構(gòu)建了一個大型應(yīng)用程序)： (What’s important for long-term users (once they’ve built a large app):)

• Ease of refactoring
  易于重構(gòu)
• Explicitness (the “do not surprise the programmer” principle)
  顯式(“不要讓程序員感到驚訝”的原則)
• Customizability
  可定制性
• Size of big apps
  大應(yīng)用程式的大小
• Performance of big apps
  大應(yīng)用程序的性能
• 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.

開源的一大優(yōu)點是它是免費的。 在這種情況下，這也是問題的一部分。

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和框架永遠不會看到開源的采用率。 但是他們也是某人的事。 與不確定的新潛在客戶相比，企業(yè)往往更喜歡長期的長期客戶。 如果技術(shù)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.

請注意：我并不是說我們現(xiàn)在都應(yīng)該開始為框架付費。 我只是在解釋為什么開源特別容易受到這個問題的影響。

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.

順便說一下，我相信這是網(wǎng)絡(luò)世界中“ JavaScript疲勞 ”的原因之一。 該生態(tài)系統(tǒng)自然會選擇易于入門的技術(shù)。 這將引發(fā)一場軍備競賽：新一代的庫和框架在新用戶面前更加容易，但擴展規(guī)模卻更大。

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”進行優(yōu)化的技術(shù)注定會變得晦澀難懂。 您最終將獲得一系列快速創(chuàng)新的技術(shù)，但這些技術(shù)對于構(gòu)建大型軟件項目并不理想。

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生態(tài)系統(tǒng)。 整個開發(fā)人員產(chǎn)品世界的周轉(zhuǎn)速度更快。 .NET Framework今年已有15年歷史，并且仍在使用中。 那是一個舊時代的殘余。 今天，即使在網(wǎng)絡(luò)生態(tài)系統(tǒng)之外，我們也看到了“統(tǒng)治”了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).

我希望我已經(jīng)證明這不是關(guān)于框架和庫所有者是不誠實，近視或愚蠢的。 這個問題是生態(tài)系統(tǒng)固有的。 它源于反饋延遲-沒人真正能做任何事情(除非他們擁有時間機器)。

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.

作為圖書館的所有者，如果您“選擇不參加比賽”，將大大損害您項目的成功機會。 您將成為技術(shù)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.

話雖如此，框架所有者可以意識到這一點。 他們可以教育軟件可伸縮性。 他們可以尋找最大的“客戶”并與他們緊密合作。 他們可以有意識地透明地強調(diào)大型應(yīng)用程序，而不是技術(shù)演示。 我的希望是整個行業(yè)都開始這樣做。 這符合所有人的利益。

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.

永遠不要聽任何沒有使用他們正在談?wù)摰募夹g(shù)構(gòu)建大型應(yīng)用程序的人。

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

(*應(yīng)用程序的大小取決于您要構(gòu)建的內(nèi)容。)

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.

這條建議的問題可能很明顯。 如果您靠它生活，您將錯過那里提供的每項炫酷新技術(shù)。 到有人建立足夠大的東西并因此有發(fā)言權(quán)的時候，您可能對黨來說已經(jīng)太遲了。

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.

  注意項目上的人員及其往績。 過去的行為是未來行為的最好預(yù)測。

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

  忽略“ hello world”的體驗。 知道使用這項技術(shù)的99.99％的時間不會是“ hello world”。

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

  警惕隱含的“魔術(shù)”。 這幾乎無法與真實應(yīng)用完美融合。

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

  僅構(gòu)建小型應(yīng)用程序或概念證明的人的折扣建議。

• 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.)

  如果您想花哨的話，請構(gòu)建“應(yīng)用程序生成器”，以使用您正在評估的技術(shù)自動生成非常大的代碼庫。 有了這個，您可以在一個下午內(nèi)近似生成一個巨大的100KLOC應(yīng)用程序。 查看生成的大型應(yīng)用程序如何執(zhí)行以及工具如何保持這種規(guī)模。 (這是Google的AngularDart團隊用來衡量自己的框架在其他領(lǐng)域的地位的做法。)

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/

她偏愛雛菊一樣的淡黃色

總結(jié)

以上是生活随笔為你收集整理的她偏爱雏菊一样的淡黄色_为什么开源项目（非常）偏爱新用户，以及您可以采取什么措施...的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。