I can't shake the dejavu feeling I'm getting using any kind of messaging these days. Today we have an awful lot of messaging apps, that are all roughly the same, with similar features - Signal, Telegram, WhatsApp, Riot, etc. This happened once already, at the dawn of 200X IM revolution that deprecated SMS for good we also had MSN, ICQ, GTalk, Jabber, etc. This also was a set of very similar personal messaging clients and protocols, similar in any way to each other. It all changed when the multi-protocol messaging apps came out - Pidgin, QiP, Miranda and others made it easy to gather all your contacts from various protocols in one place and to keep in touch with everyone. Shortly after Jabber transports were made so you could congregate all other accounts into one single XMPP account. Even N900 that came out in 2009 had the ability to gather various accounts into one single contact list.
I feel like right now with all the segmented IM apps it's a good time for something like this to happen again, and Telegram already has wat-bridge.
What are your thoughts on that topic? Do you think the history will repeat itself? Would a new federated formate like XMPP rise up?

I received this email yesterday but haven't seen any blog posts or press releases about it yet:

Hello Administrator,

Since our Beta Program announcement last year, we’ve been testing an enterprise-ready version of Google Voice. Over the next seven days, Google Voice will become available as a core G Suite service for all eligible* G Suite customers (additional fees apply to this new, managed version of Google Voice). This email will help you understand the transition details but you can also refer to the Voice webpage for more information.

What's changing:

• Managed Google Voice is available in 3 tiers and will become a core G Suite service for your domain after subscribing to a service tier.
• Managed Voice accounts will be covered under your existing G Suite agreement and additional Google Voice service specific terms.
• Support for managed Voice accounts will be the same as other G Suite core services.

What's not changing:

• The Google Voice service will remain “on” by default.
• If users in your domain signed up for Voice prior to this launch, they will be able to maintain their legacy unmanaged Voice subscriptions without additional cost, and will remain subject to the Google Voice consumer terms of service. You can add a Voice subscription and upgrade these users to managed Voice users in your Admin console.
• Hangouts Meet (also a core G Suite service) is integrated with Google Voice, allowing meeting participants to dial in or be added by phone.

What do I need to do?

• If you did not participate in the Google Voice Beta Program and would like to use Google Voice for your organization, follow these steps to add a Voice subscription.

We're here to help

If you have additional questions or need technical assistance, please contact Google support. When you call or submit your support case, reference issue number ----------.

Sincerely,

The G Suite Team

* Google Voice is not yet available for G Suite for Government customers. Google Voice is available for purchase in select countries.

It looks like Google Voice is going to be sticking around for awhile. You can even use Polycom desk phones with it if you get the $20 tier.

It's obviously bad when "real" data like full names and credit card info leaks, but most data companies collect is probably email address and some anonymous things like which buttons and when the user clicked.

Nevertheless, such data collection, tracking and telemetry is considered quite bad among power users. I don't support those practices either. But I'm struggling to consolidate my arguments agaist data collection. The one I'm confident about is effects on performance and battery life on mobile devices, but why else it's bad I'm not sure.

What are your arguments? Why is it bad when a company X knows what anonymous user Y did and made money on that info? What's the good response to anyone who asks why I'm doing the "privacy things"?

I'd like your input for an article I'm writing.

Let’s say you’re starting a new IT project. It could be custom software; perhaps it’s a migration to cloud services; maybe it’s a shiny new IoT project.

The point is that you're here to build something great. You’re in charge of the design (or an important part of it), and making sure that the resulting system makes everybody happy.

How do you make sure that you are interviewing the right people to find out what “make them happy” looks like? What do you do to get input from the people who matter for the project’s success… without inviting so many suggestions that it’s impossible to deliver everything?

Case in point: Ten years ago I was in charge of an online tech community. The company I worked for hired custom developers to build the software platform, but the developers never talked to me. They interviewed the boss, two levels above me (who just so happened to be the person who signed the checks) even though she had never used this online community or any other. Needless to say, the community software they delivered was horrible, missing basic-to-me features.

Formally this process would be called “identifying the project stakeholders” or “master the requirements-gathering process” but that seems too corporate-speak. I’m looking for real-world examples of what works and what doesn’t, so I can write a genuinely useful article with practical guidelines.

Note that this is NOT about the questions to ask those stakeholders; that’s another discussion. Here I am writing merely (merely!) about making sure you are speaking to the people whose input you need.

My questions:
• How do you decide which people to ask for input? In what way do you find those people? How do you know when you have everyone you should?
• How do you decide whom NOT to invite? Where do you draw the line?
• Tell me about the manner in which you learned that lesson. (The hard way. Anecdotes are good.)
• If you want to be quoted (it's good for business!) tell me (via PM) how to refer to you in the article: Name, title, company name, short company description, URL.