<div dir="auto"><div dir="auto">Thanks for putting this together! Some (late and) minor thoughts on wording:</div><div dir="auto"><br></div><div dir="auto">I like that we state we want to "integrate well with other Free products to complete the experience". I would explicitly mention "other Free *software* and products", to make clear that we don't want to be a closed ecosystem where KDE software only integrates with other KDE software. </div><div dir="auto"><br></div><div dir="auto">I also think that the statement "maintains a diverse and inclusive community" is fundamental in a truly open online community nowadays. I would go further and say "a diverse, inclusive *and safe* community".</div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Apart from that, I agree with every point in the strategy and I'm happy we have decided to write it down and make it public.</span><br></div><div dir="auto"><span style="font-family:sans-serif"><br></span></div><div dir="auto"><span style="font-family:sans-serif">Albert</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On May 30, 2017 11:55 AM, "Sebastian Kügler" <<a href="mailto:sebas@kde.org" target="_blank">sebas@kde.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Agustin,<br>
<br>
On Tuesday, May 30, 2017 4:07:37 PM CEST Agustin Benito (toscalix) wrote:<br>
> thanks for driving this discussion. It is a needed one. Here are my<br>
> early comments:<br>
><br>
> * "builds on open standards to prevent "lock-in" - I think that<br>
> prevent lock-in is not a reason but a consequence of building KDE<br>
> software on open standards. open stardars are aabout transparency,<br>
> agreement, provenance...<br>
<br>
That makes it too vague in my opinion. Preventing lock-in is a tangible<br>
benefit for our users, it is in fact why many instituional users choose Free<br>
software over proprietary offerings. We should call it by its name to make<br>
clear why we do this, and why users want and need it.<br>
<br>
> * "provides usable security and privacy features to protect against<br>
> surveillance and data theft" there is legal surveillance that we do<br>
> not want to prevent. In any case, privacy is a right challenged in our<br>
> digital era like was not challenged before, in the analogic era. Is<br>
> the right to privacy the central point, not the prevention against<br>
> data theft. You can prevent your data from being stolen through<br>
> proprietary software too, among other options.<br>
<br>
Legal says exactly nothing, since it's bound to a jurisdiction, a concept<br>
which doesn't exactly work in the internet era. Something can be legal in a<br>
given location, yet morally wrong. Also, we're not judging (a Free software<br>
principle), we're allowing privacy, full stop.<br>
<br>
> * "have consistent, easy to use human interfaces" and "provide a<br>
> seamless user experience" seems to me close enough to justify that we<br>
> condense them in a single statement.<br>
<br>
One is about the interface quality itself, the other is about a cross-device<br>
experience, I think they warrant separate mentioning to make the mission less<br>
fluffy and more concrete.<br>
<br>
> * I would be carefull with the words "integration" and<br>
> "interoperates". In order to work well, both concepts requires two<br>
> parties. We cannot guarantee any of them by ourselves.<br>
<br>
We can strive for it, however. Nothing wrong with that.<br>
<br>
> * Linked with the above, this statement is a set up for failure:<br>
> "interoperates well with proprietary software, formats and services" .<br>
> In simple words, it is not in our hands to provide a satisfactory<br>
> experience when dealing with proprietary software/formats/services. I<br>
> would re-formulate this in a way that reflects that we will do our<br>
> best.<br>
<br>
Again, I think it's absolutely sound to state that we want our software to<br>
work well with proprietary offerings. It provides real value to users and<br>
again makes it clearer why we do what we do.<br>
<br>
> * "empowers users independent of their abilities" I find this<br>
> statement vague. How are we going to empower them? what for? why it is<br>
> so important for us to empower software users? I would try to develop<br>
> it a little.<br>
<br>
How? :)<br>
<br>
> * I have a fundamental issue with the whole "user story". We are<br>
> upstream. We only reach 0.1% of our currrent users directly. We live<br>
> in an industry that has "downstream", that is, integrators and<br>
> distributors. I truly believe that one of our limiting factors is our<br>
> belief that we can reach users "by ourselves", through direct<br>
> interaction. This idea, which is popular in our community, has its<br>
> reflection in this Mission statement. No mention to any collaboration<br>
> with dowsntream in this section, to reach users.<br>
<br>
While we are upstream, we're responsible for the largest part of the user<br>
experience, we develop the software, we create the UI, we fix the bugs that<br>
annoy people.<br>
<br>
> I have been fighting this widespread belief since I joined in 2005.<br>
> Our situation is worse today than ever was, in my opinion. I would<br>
> really like to see ourselves turning the situation upside down, which<br>
> can start by discussing and ultimately reflecting in this Mission<br>
> statement how important it is for us the ecosystem that allow us to<br>
> bring our software to user's hands.<br>
<br>
Please elaborate what you want to do, and how. Your statement is really vague<br>
and I fail to make sense of it, possibly others have the same problem.<br>
<br>
Cheers,<br>
--<br>
sebas<br>
<br>
<a href="http://www.kde.org" rel="noreferrer" target="_blank">http://www.kde.org</a> | <a href="http://vizZzion.org" rel="noreferrer" target="_blank">http://vizZzion.org</a><br>
</blockquote></div></div>