Don't blame the developer advocate for the company's mistakes. Developer advocates rarely have any part in these kinds of decisions, but are left holding the bag whenever they go badly.
The original TSM engine is still used by InfluxDB v2 OSS.
The InfluxDB Cloud platform uses a variation of TSM that's tailored for a distributed SaaS rather than stand-alone nodes (this was originally intended to be used in InfluxDB v2 OSS as well, but alpha-testing showed that the old engine performed better there so it ultimately was reverted for the beta release).
So IOx is really the first major new storage engine in InfluxDB.
So many things are qualitative, but not quantitative. They can be measured, but not counted. Happiness is one of those, you can say that you are "more happy" or "less happy" from one day to the next, but you can't count happiness, you can't put a number on it.
I'd recommend reading The Community Engagement Trap[0] by Rosie Sherry (which should also be shared here on HN), she talks about Community Discovery as the process for getting these deeper understandings.
That's like saying grocery stores are exploiting the human need for food.
A healthy community benefits the people in it as much or more than the company behind it. As you identified, humans have a need to connect with other humans. And often they want to connect around a product, service or hobby that they share with other humans.
It should also come as no surprise here on Hacker News that humans also really like to tell companies what they think about their product, and how to make it better. They also like the appreciation they receive from helping others use the product better.
A company-backed community serves a need that the members of that community have. Nobody is being forced into it or exploited. We're giving each other a mutual benefit that, as long as it remains mutually beneficial, we are happy to keep investing in.
A user's engagement with your product is a great metric, because what you value is users using your product.
But for a COMMUNITY it's the wrong metric, because you don't value negative comments in your Slack no matter how many there are (in fact, the more there are the worse it is).
> I don't get it. What is a "community manager"? Is it someone that runs a company's social media page?
No, that's a social media manager, completely different role.
> And do they think that people care about their brand so much that they would join a community of people whose only common trait is liking the same brand?
Yes! It happens all the time. Most of the biggest brands have a community of people who share that common trait.
> And in the first place, how do you even build a "community" manually and artificially?
Again yes, just like you build a garden. The gardener doesn't make the plants grow, but they do make sure they have the right environment and resources to grow in.
> The article implies that community building should be some kind of altruistic purpose, where your only goal is to maximize the amount of "meaningful relationships" created?
That's not altruism. Those meaningful relationships help the company/project the community was built around. They provide feedback, help improve processes, make connections outside the company/project, provide support to other users, there are too many things that communities do to list them all here.
You don't advertise to your community. If you do you're actively killing it.
Community is made up of people making connections and building relationships with other people. Savannah CRM helps you manage those connections and relationships.
InfluxData doesn't make money from Telegraf at all. It fills a need (data collection) that InfluxDB users have, so it helps them which helps us, but it also helps our competitors whose users also use Telegraf to collect data.
The reason merges have been a problem is that historically there was only a couple of people involved in the project doing all of the code reviews, and new plugins are usually large chunks of new code that interact with products or protocols those reviewers aren't familiar with, so there is a steep learning curve just to properly review code contributions.
Last year we formed a new maintainers team that is a mix of InfluxData staff and community contributors who are working together to review and land code changes. This has significantly increased the rate they're getting through PRs but there's still a very large backlog to get through, plus new stuff coming in all the time.
Anybody who wants to see new code and plugins land in Telegraf faster can ask to join the maintainers team. You'll need to be familiar with the codebase and willing to work on any plugins of functionality that come in (a lot of plugins come from people building things for their own job/product).