Brainstorming about ecosystem, userbases and codebases

[Elias Batek]

Hi everyone,

Today we had an interesting discussion on the matter of 
“attracting new people” on Discord. This reminded me of a few 
thoughts that I had originally planned to write down earlier in 
January. So here we go.

Looking forward to hearing your thoughts, ideas and objections.
I might be wrong about certain things, but I’m certain that I can 
thankfully rely on you to point things out. Thank you!


Preamble
========

So, there’s the issue that the ecosystem, tooling etc. heavily 
relies on users and their time. Polished tooling – the “just 
works” experience – requiring huge budgets, people come to the 
conclusion this area might need corporate sponsoring. And in 
order to achieve that we’d need more users. The chicken-and-egg 
situation aside, I sometimes see an uncomfortable focus on the 
“new users” part of the growth.

If you focus on people that don’t use D, you won’t focus on 
people that use D. Implication is, at worst, the second people 
start using D, you’ll cold-shoulder them too.

Nothing new, probably; we’ve had a bunch of threads on that.
On the other side of the coin this focus on fresh users is a 
“threat” to (not only the size but) the quality of ecosystem as 
well.


The “user zero” problem
=======================

Ideally, code that is written would have a known use-case and 
user.

While there’s nothing wrong with code written for pure personal 
interests, it doesn’t add direct value to the ecosystem and isn’t 
exactly meaningful to consider in this discussion. Such programs 
were written with the goal of writing them, learning something 
along the path and trying things out. This sure is not only a 
reasonable thing but also valuable; nevertheless, neither a 
potential user of the code nor the ecosystem is a concern in that 
case; it’s all about the process not the end-product. So let’s 
focus on code that is written with the intention to be used by 
someone instead.

There are several options who could serve as the first user (aka 
“user zero”) for a piece of code:
- The author themself. – That’s great! Not only can issues and 
shortcomings be reported bypassing complex official channels, the 
people in charge of writing are also aware of practical 
limitations and chances of in the field application.
- A friend or coworker. – Shiny! Feedback will easily come in. 
And the author will likely get to see how the code in question 
performs in practice (usability, applicability, correctness etc.).
- A client or employer. – Awesome! In this case it doesn’t matter 
whether the code will actually be used; as long as the money 
comes in.
- A target group or target audience. – Alright… So we don’t have 
an actual user here yet, do we?

The reason why user zero matters is because they are the first 
entity that gives the code a purpose. (Remember, we’re still 
referring to code that wasn’t written for the sake of 
learning/experimenting with it/writing it.)
Their experience helps to identify bugs, shortcomings, missing 
features and in general ensures that the codebase is fleshed out 
well. User zero eventually gives the author a reason to maintain 
the code, too – given enough altruistic nature in them.

Code with no users tends to lack all that. And when finally 
someone tries to use it, they might run into unforeseen issues 
and the codebase crumbles down. Not to mention the disappointment 
of the user who will find themselves left with the decision to 
either try to fix a codebase (that was never truly designed to be 
actually used) or having to look into alternatives.

So, in my humble opinion it’s a common misconception that in 
order to get bigger, D would need to attract new users. Instead I 
think the community should focus on strong company and writing 
code for an actually existent user.

Because targeting the current users is what keeps them from 
leaving.
Unless fluctuation/turnover is the goal, retaining existing users 
is at least as import as recruiting new ones. Keep in mind, any 
new user that isn’t retained nullifies themselves in the user 
count. If they leave on bad terms, we’ll need 10 more happy users 
to make up for the negative word of mouth – according to what I 
remember from the economy class in school.


About “target groups”
=====================

“Target groups” is a marketing term. It doesn’t refer to a group 
of users. It refers to a group of potential users. Those may or 
may not even consider using the product – the code, in this case.

The unfortunate implication of writing code for a target group is 
that it isn’t code written for a an actual user. There is no user 
zero.

What can be said about a piece of code, can also be applied to a 
programming language as a whole. A popular target group here 
would be employees of big tech that could bring in manpower 
and/or money to improve ecosystem and tooling.

But, unlike users, one doesn’t reach target groups with providing 
or offering a product. That’s where marketing comes into play. 
And marketing usually needs a sales pitch or similar. “Tooling in 
D isn’t great because we don’t have big money. Give us money and 
we will make tooling great again! (Oh, and we have a great 
programming language.)”, doesn’t make a good elevator pitch.

People often don’t realize that substituting themselves with a 
target group in their statements actually hurts their arguments. 
In this regard, Paul has observed the following:

> Also, "what new users/users of other languages want" is 99% of 
> the time a justification for some individual’s  personal 
> preferences, rather than, like, a statement backed up by any 
> kind of data.

While a single user might not be a suitable demographic in the 
context of a programming language in the first place, when 
mentioning a group of potential users instead, it even removes 
the first (and only) actual user from the equation.

If we do it for someone who isn’t using D, we could instead let 
it alone in the first place.


Comments
========

I’m not here to tell anyone how they should write their code or 
what they should spend their time with. Neither do I want to 
imply any authority on judging how other people should spend 
their time. All I want to say is, if you want to see the 
ecosystem and user base grow, you should probably look forward to 
participate in that as well. And write code with an actual user 
in place (not in mind).

By the way, this whole user zero thing reminds me a bit of 
Walter’s stories about programs he wrote where other people said 
they would see a use-case for, but ended up not getting used by 
them. I don’t want to put words into Walter’s mouth, but to 
connect things together: I see the lack of a sustainable user 
zero in those cases.

--

PS: Feel free to start your own newsgroup thread for off-topic 
discussions. Please do me a favor and don’t derail this one. 
Thanks in advance!