[kde-community] Fwd: KDE Vision – towards “wholesame” solutions
neundorf at kde.org
Sun Feb 14 22:57:56 UTC 2016
On Saturday, February 13, 2016 13:12:52 Lydia Pintscher wrote:
> On Sat, Feb 13, 2016 at 7:45 AM, Olaf Schmidt-Wischhöfer
> <olaf at amen-online.de> wrote:
> > sent to wrong mailinglist by mistake ...
> > ---------- Forwarded message ----------
> > From: "Olaf Schmidt-Wischhöfer" <olaf at amen-online.de>
> > To: kde-ev-membership at kde.org
> > Cc:
> > Date: Fri, 12 Feb 2016 22:19:00 +0000
> > Subject: KDE Vision – towards “wholesame” solutions
> > Hi all,
> > many thanks to all people that have worked on the vision proposals and to
> > everyone who contributed thoughts.
> > I would like to chime in with an aspect that I feel is missing so far.
> > This additional aspect is closely related to the motivation behind the
> > product-focussed draft, but my conclusions are completely different.
> > Already in KDE 2 and KDE 3 times, it impressed me that the software both
> > offered a high degree of flexibility (through modularity and many
> > configuration options) and a high degree of consistency (through clever
> > and
> > integrated solutions via the libraries). This tendency increased later
> > during Plasma 4 and Plasma 5 times with a restructuring of the KDE
> > releases. We now offer far more flexibility to users of the libraries (no
> > monolithic “kdelibs” any more). We also changed the release structure to
> > support the fact that both the libraries and the applications can be used
> > independent of the desktop – while keeping the good integration into the
> > desktop.
> > The flexibility aligns well with “enables users to control their digital
> > life” (from the value-based draft).
Actually the product-based draft had that earlier, there was cross-pollination
between the two :-)
( https://community.kde.org/index.php?title=KDE/VisionDraftA&oldid=45297 )
> > The consistency is, I think, what
> > motivates the product-focussed team.
this, and even more that we want to put the product into focus again.
> > This can be done via cooperations (OwnCloud, Kolab), but it other cases we
> > will be better off if we allow our own developers to work on solutions.
> > Forcing them to migrate to a different developing community will seriously
> > harm us in our quest.
> > For this reason, I am deeply concerned about the restrictive wording of
> > the product-focussed draft – even if a similar motivation moves me.
> > Regarding the value-based draft, my feedback is that it is very
> > well-written. I truly like it. I am convinced, however, that we need to
> > stress somewhere that the various KDE projects aim to integrate well with
> > each other. This can be in the vision, or in a Mission statement, or in
> > the Manifesto – but it is needed if we want to address the fear that KDE
> > will loose focus.
I fully agree with your point that local software should be well integrated
with online-services, and that KDE should try to provide that.
You say the wording is "restrictive". What exactly do you consider restrictive
Do you understand "to achieve that, we work on:" as "we work on exactly that,
and nothing else" ?
Our intention is to say that those 4 items are the main focus, which we work
on, and of course everything that supports those (I said that already earlier
in some mail). So online-software that integrates well with the local
applications is also in scope.
What's not in scope would be online-software that has no relation to the local
software (as you say, nothing would be integrated then).
Having said that, it is just a draft, a suggestion.
Not that much effort has been put into the exact words.
Also the 4 items are just a suggestion.
Olaf, if you think those could be modified or something added, please say so.
> I agree that integration within our projects is important. And I
> believe it has suffered lately as the cohesion inside KDE became less.
> My gut feeling is that this should go in the mission.
> > I would suggest a sentence like the following:
> > “KDE aims to offer complete, well-integrated solutions – while connecting
> > different platforms, devices and online services.”
> That sounds good to me.
To me too, but I still miss the reference that it is about software with
graphical user interfaces (GUI's can also have gesture or voice input etc.),
which Olaf seems to imply too.
I mean, we are not targetting e.g. sensor networks built from 8bit uCs
communicating to some big online server, with no user intervention (which
would fit that description too), or are we ?
> > Before we finally agree on a vision, we need to clarify how it will relate
> > to the Manifesto – and what will happen to KDE projects that do not fit
> > to the vision.
> They should live side-by-side. One defines who we are and the other
> defines where we want to go.
I think everybody agrees to that.
> > I consider it extremely important that we have clarity on the following
> > questions, and would like to hear an “official” answer from both teams:
> > 1. Will the Manifesto will stay the only official guideline for joining or
> > leaving KDE? And will the vision have a purely advisory role?
> IMHO we should not take the vision as an exclusionary tool but as a
> reminder of where we want to go - an advisory role as you put it. It
> should be there to remind us of the big picture and the change we want
> to see in the world.
Whether KDE wants to be open to projects which are not supporting the
vision/mission does not really depend on which vision/mission we come up with.
> > 2. Or will we revise the text of the Manifesto in the same vote where we
> > accept the vision?
> As Kevin already brought up some time ago we can revise the manifesto.
> I would suggest however to not do this in one go. I fear we're biting
> off more than we can chew otherwise.
> > If we change the Manifesto, then we also need to clarify:
> > a) Will KDE projects be expelled if they do not fit the new Manifesto?
just IMHO: this would be very bad style.
> > b) Or will KDE projects be allowed to stay even if they do not meet the
> > new
> > Manifesto? Will other KDE projects then be forbidden from working on code
> > that goes beyond the focus of the Manifesto (even if the developers
> > consider it necessary for the future of the project)?
Those fall under "supporting/related to".
> > c) Or can existing KDE projects can do whatever they wish – while new
> > projects are forbidden to join unless they meet the focus of the
> > Manifesto exactly (even if they integrate well with other, existing KDE
> > projects having a different focus)?
I think this question is quite theoretical, and we could spend a lot of time
on discussing complicated scenarious, so from my POV there is no short and
If a KDE developer starts an unrelated project using the KDE git server,
practically this would mean this guy would have to be told to go away and use
some other git server for his stuff. I don't suggest doing this.
OTOH an unrelated project may actually be better off somewhere else. E.g. IMO
extra-cmake-modules would be better hosted e.g. on github, so it would be
easier for non-KDE-developers to contribute.
But I think we don't *need* to attract unrelated projects. That's why the
vision/mission should somehow define what the "core" is, so we can actually
talk about whether something is related to that or not.
More information about the kde-community