digitalmars.D - Brainstorming about ecosystem, userbases and codebases
- Elias Batek (124/128) Feb 04 Hi everyone,
- Guillaume Piolat (25/32) Feb 05 My 2 cents:
- Andrea Fontana (9/12) Feb 05 Haha thanks :). Just because I'm used to working with people who
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!
Feb 04
On Sunday, 4 February 2024 at 21:29:14 UTC, Elias Batek wrote: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).My 2 cents: - Every user that came to Dplug told me the same story: "The examples built.", and they did not for competing frameworks for them. The most important thing you can do for user acquisition is to check that your examples actually build, in several OS. People have a variety of OS and D configurations and it can prevent getting to user zero. I see it over and over for every library presented on these NG. arsd were a perfect example of how many users you can attract if your code build (and even then I had trouble with minigui, and didn't use it). - When "user zero" or "user <n>" wants a bug fixed, and you fix them, do not forget to update the DUB git tag and tell them to "dub upgrade". Fixing it in ~master doesn't solve their problem, right? - Traditionally people says documentation must be of several type: inline doc, per-case idioms, blog post about topic, exhaustive reference... I find that the most effective type of documentation is of the per-use case idiom. A list of problems and their solution, ready to be copy/pasted. People certainly do not care about what beautiful abstractions you elaborated, only what problems your code can solve for them. One of the library that does that perfectly well is `serverino`, which will go on to explain how to put a reverse-proxy in web servers.
Feb 05
Andrea Fontana <nospam example.org> On Monday, 5 February 2024 at 12:32:46 UTC, Guillaume Piolat wrote:One of the library that does that perfectly well is `serverino`, which will go on to explain how to put a reverse-proxy in web servers.Haha thanks :). Just because I'm used to working with people who don't know D that well. There is a big problem with the default installation IMHO. Many people use macOS and dmd simply doesn't work out of the box on newer machines. This is a big red flag for new users I've talked to. Andrea
Feb 05