If we want to "win" (reach similar/higher adoption), we need to at least come close. It's not easy work, but not doing it and leaving the product that so much good work has ready gone into unusable for a vast number of people would be a bummer.
If we want to "win" (reach similar/higher adoption), we need to at least come close. It's not easy work, but not doing it and leaving the product that so much good work has ready gone into unusable for a vast number of people would be a bummer.
That kind of users aren't worth the hassle if they have no money.
I personally have better relationships with people that enjoy learning something new, and coming up with solutions for issues themselves, eventually contributing to the ecosystem.
Then we should add deliberate errors in the signup process and encourage the community not to talk about them so there's a definite right of passage.
> I personally have better relationships with people that enjoy learning something new,
Here's another perspective. I love learning new things. But this is making me learn the internal product releases of a chat app rather than, say, what the different lions represent in the dance I watched on Chinese new year.
Or worse, you're making me learn what the split is between matrix the spec, matrix the hosted server, the matrix foundation, element the business, element the hosted service, element the app and the other element the app - rather than pretend to be an imaginary creature called a meep with my daughter.
But it's still important not to make people waste their time. End users should be sent to an end-user friendly place, and developers should be quickly sent off to usable development documentation.
It doesn't help anyone to confuse people and have them figure out the details of the internal organization and convoluted relationships between various pieces before they can even start doing work.