她偏愛雛菊一樣的淡黃色

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團隊用來衡量自己的框架在其他領域的地位的做法。)