[kde-community] user stats for Neon

Thomas Pfeiffer thomas.pfeiffer at kde.org
Thu Apr 21 00:58:34 BST 2016


On Mittwoch, 20. April 2016 15:49:12 CEST Agustin Benito (toscalix) wrote:
> Hi,
> 
> (long mail)
> 
> I went through this same discussions a few years ago in openSUSE. Let
> me outline my personal experience/point of view through that
> experience.
> 
> At some point, openSUSE was in crossroad and those involved in taking
> action, including myself, were not able to agree on the diagnosis of
> the situation. So it was impossible to agree in the next steps.
> 
> In short, my take on that situation was:
> 
> no data -> no common language -> no objective analysis -> no shared
> diagnosis -> no alignment  -> no improvement
> 
> I took the decision to collect and analise data as a key input for
> taking decisions. We worked with UID in combination with existing
> download/page hits numbers to support answers to simple questions
> first and more complex ones over time.
> 
> Leaning from what happened to Canonical in a similar situation a
> couple of years earlier, some requirements were established. The main
> ones I remember were:
> 
> - Transparency about:
> 
> * How we were going to collect the data.
> * What was going to be used for.
> 
> - Publication of the process to collect the data and the mechanism to
> disable it in your computer.
> 
> - Publication of the analysis on regular basis.
> 
> - Protect the raw data so it could not be used for any other purpose.
> We applied measures to ensure that no identification was possible,
> like linking UID to IP and geo info, in the line of what Kevin pointed
> in a previous mail in this thread.
> 
> Despite our efforts to implement a perfect process, trust on those
> handling the information was a requirement for this action to succeed.
> This is always going to be the case, right?
> 
> I had to suffer strong criticism back then, even in public, specially
> from relevant community members. Many did not trust me nor those
> handling the info. Others simply did not understand the need and
> potential impact that this measure would have for the project. Some
> also feared that the project would start becoming "data driven"
> instead of "people driven".
> 
> The impact of the action has been huge. In my opinion, way bigger than
> most think, specially at that time.
> 
> What today is Tumbleweed, Leap.... would have been different, way
> worse, without the learning process those involved back then in
> openSUSE delivery went through as a consequence of this action. We
> talked less and less about our personal experiences and impressions
> and more and more about the interpretation of the data. A first and
> necessary step towards reaching a common diagnosis.
> 
> Over time, this action stopped being controversial. I think that now
> the outcome of this action is seen within openSUSE as an asset.
> 
> Fedora recently presented at FOSDEM similar analysis to the one done
> by openSUSE. They even extended it and agreed on the potential impact
> in the decision making process that this action will have in the
> future of the project.
> 
> KDE will be criticized too. Even some of our community members will
> claim that our core principles are being violated. But in my opinion,
> those criticisms are unfair, at least until the result of this action
> is evaluated. The risk to screw it up is there, but risk is something
> that can and should be managed.
> 
> No doubt that privacy is a core value in Free Software. I assume it
> and defend it. But understanding how our software is consumed and by
> who, instead of pretending we know what users want and how they use
> KDE, is essential to improve, to increase the value we provide to
> them.
> 
> In summary, to me back then, it was a matter of putting our users and
> the project first, even before my personal values. It was a tough
> decision but I would take it again.
> 
> So my suggestion is:
> 
> * Let's do our best to be transparent about our goals, process and output,
> 
> * Let;s provide a simple way for those who think that collective
> ignorance is an affordable side effect of privacy to not participate
> on the data gathering, They have the right to think that way and we
> should respect it. We should work hard to prove them wrong. We have no
> spurious intentions.
> 
> * Let's make sure we establish a trusted process and rely on trusted
> people for this action. We already has proven in other areas that we
> can trust ourselves when dealing with sensitive topics/info.
> 
> * Let's assume we will be criticized for this. We will need to put
> energy in explaining our intentions and motivations but that will
> never be enough for some, even if we succeed.
> 
> But let's also assume also that:
> 
> * Ignorance is already hurting us. Again, no, we do not know what our
> users want and how they consume our software. This ignorance has deep
> consequences for the project.
> 
> * Even if we share a vision, it will be impossible to align as a
> community if we do not agree where we are. Speak the same language is
> a requirement to reach a plausible diagnosis, a requirement to take
> the right actions to accomplish the shared vision. Numbers are a key
> part of the solution, not the problem.
> 
> * It will take time, but if we improve as a consequence of this
> action, those who do not trust today that privacy and science are
> compatible, will at least understand that the sacrifice might be worth
> it for most. This is a very positive outcome.
> 
> So...
> 
> please, leave your fears behind. Let's give such action a try. Let;s
> bring some light. I think that KDE, as openSUSE back then, desperately
> need it.

Sooooo much +1!
Action has to be taken with utmost care, but it has to be taken. We cannot 
afford stumbling through the darkness for much longer.

> Note: it would be very interesting to talk with Alberto Planas, the
> person behind the openSUSE data analysis action, in order to better
> understand the risks and how openSUSE deal with them today. Also to
> better understand the potential benefits.

Cool, we should get in touch with him.





More information about the kde-community mailing list