latest draft for mission (and strategy)

Jens Reuterberg jensreu at kolabnow.com
Sun Jun 11 20:53:48 BST 2017


Like Albert I mostly want to weigh in that I support the mission draft - 
personally I consider the existance of a mission draft the central core 
success. 

It's one thing to be in opposition to parts of an existing mission - a 
completely different one when you may or may not be in opposition with the 
community. One of them means a debate can happend - the other just means 
deadlock so a mission in itself is a success.

As a sidenote to Agustin I consider the user story angle relevant, if not 
critical to a mission statement. Cut out the user from the equation and the 
whole idea of even providing a UI becomes redundant. 


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





More information about the kde-community mailing list