mehdim's comments

In bullet points : - GDPR is a risk management policy about personal data protection more than a privacy regulation

- for any personal data (PII) all companies must declare the following :

  - purpose of the collection and the treatment of the specific data

  — legal base of the treatment (6 available, they are the field card in Magic the gathering, they define a context of what is possible to do)

  - data category (what type of data you are collecting i.e if you declare collecting delivery shipping information for a purpose, you limit yourself to data that correspond to that category )

  - data retention duration (how long you declare storing the data in production and then in archive)

  - list of recipients (all the 3rd party companies who will access the data)

  - security measures (what is the level of security for keeping that data safe from breaches)

  - some infos about the company, the data controller (who is responsible) etc…

So all companies must do a internal data mapping to know and declare where is the data and where it flows in production and write for every PII a ROPA (record of processing activity) You can find an open source specification UROPA here)

https://github.com/uropa-project/uropa

- consent is just one of the 6 legal bases to collect and treat data. The comment above that everything is possible with consent is wrong.

- below 250 employees you don’t need officially a DPO

We are building one such service and I agree (to name a few services doing GDPRaaS : soveren.io, ethyca.com, securiti.ai, datagrail.com, alias.dev) .this is so much needed as there is almost no legally valid answer on the whole comment section! I started to write an article on all the points above… should get back in 2 hours and post it here

I am a multiple meetup organizer and owner on meetup.com and I find it actually great that the meetup can stay alive if the organizer stop to pay. Your communities are not owned by you. Also, they don't give subscribers infos but just "an access" to send them email communication to the list, not the "list" with email list etc...

Either you don’t do business anymore with Eu users or any user on Eu territory (but how do you know there are not actually on Eu territory), either you try to automate it so you continue to “not care about it”

Yes! an "Echoes for Open source" contributions may be one day. Nice work btw, I will try Echoes with my team.

Nice. Do you plan to match it with marketing/sales budget per product line or Business unit? To be sure that the effort of "maintaining legacy" is equally measured versus over funded efforts on new features for growth?

Disclaimer : I am running a non profit in my country called "The Maintainers", this is why I look for products that can give more merit to code maintainers.

What is the "Unit of technical/economic value you identify for that? You do it at the Commit level? Build? Deploy?

We have never been successful showing that internal maintainers of the legacy were the ones really paying the bills and delivering the current value of the company. Fame and payroll was mostly towards the cool engineers working on new tech not yet in production serving real customers. I hope Echoes helps giving merit to the one contributing to the economic value of the company

I made a list of all resources on privacy engineering, including meetups groups, tech conferences on privacy engineering https://github.com/progressive-identity/privacytech-resource...

The link between "groups never admit failure" and "non-profit organizations are not sustainable by design" is a little bit too direct and non relevant.

Lots of non-profits make revenues, selling stuff with customers, they just don't pay dividends by design and re-invest everything. So what he says does not apply.

And again, even foundations are at least oriented to hear feedbacks from donators who are their "customers". So it does not apply here.

The only valid point is that yes, group never admit failure as a whole, but the post should have stopped after this

Updated : not "well maintained". Or not enough maintained compared to their criticity and their global use.

Co-author here of the research. The most simple and effective and rapid solution would be to impose API neutrality. As explained in the report, it would just obliges API providers to give back the same API access to users than they give to their partners. For instance, why I get less data from Facebook if I ask my personal data, than if I create an app and ask maximum app permission (all OAuth scopes)? API neutrality already works. For instance, Open banking in UK and PSD2 in Europe apply API neutrality. Any 3rd party can access to a bank API if they are granted by the user to do so. After 2 years, for instance, up to 20% of the UK online banking population beneficiated from it as "Banking data Portability via APIS" . 20% is huge. If FAMGAs and all other big companies data was accessible via "neutral APIs" to users, data portability would be "a thing"

Also, the fact that you don't know what to do with you data dump in JSON is a blocker. With APIs, integrations by 3rd parties are simpler and more user oriented.

Last point, with API neutrality, no need of maximizing "interoperablity" (even is is always useful and makes things simpler, we have seen that with DataTransferProject it does not work really as companies don't work with the same data model) Developers will do the matching work between the original app and the destination app, no worries, when incentive is here, middleware glue will come. The problem these days is that the source of data is useless, has no value, so no incentive. You can look at this study with GDPR Facebook data value for developers https://www.law.nyu.edu/centers/engelberg/pubs/2019-11-06-Da... The main question is : Why a Facebook GDPR Data dump/takeout has no value for developers where Facebook API has value for millions of applications developers and businesses? With API neutrality it will have maximum value for users (as it has already value for partners) and minimizing fatigue to implement portability (an API is lot more developer friendly than a JSON dump that you receive in 30 days via email and that the user need to upload somewhere)

author here. We divided the number of revenues and the marketcapitalization per regional revenues US user : $1294 market cap in average, EU user : $494 market cap in average, Asia $109, Rest of the world $80 It is explained in more detail in the report

This is why, according to GDPR and CCPA principles (it is not written as is in the text) we need to include API neutrality for users, as the right to have an API access to 3rd party applications to exercise users' data portability regulations. All of this without the possibility of the company to revoke API access. Like the net neutrality, but for APIs. https://api500.tumblr.com/post/31465739810/what-is-api-neutr...

to get more financial support for Homebrew, did you try a maintainers' trademark contract? You can see an example here https://framagit.org/inno3/tm-contract-for-oss-maintainers/t...

no, no blockhain. Just OAuth2.0 decentralized with DNS, as the authorization server and the resource server can be behind 2 different domains.

AlphaGo is dead... we need BetaGo for this one.

This is the next feature to be added. Come back check the October release, with User management and Payment addons. MySQL was asked by lots of users since launch 3 weeks ago.

I like how you try to growth hack the Growth Hacking Slack with referral viral engine to get in. Nice try.

I really love the execution. Neat, slick and they even had the luxury to be open about it in their blog. They attacked a simple-to-understand but real problem, on a niche, making something people wanted to have and not wanted to do. They built the right integrations...making money since the beginning, increasing revenue per user and overall revenue... They probably made lots of mistakes , but according to public information and taking the time to analyze it with some prospective, they did (almost) everything right. Following their traction and revenue, they must have sold for a good price as Atlassian really needs such products to renew their platform and they have the portfolio of customers Statuspage would have tried to acquire. Great story.