+100,000

Nice tight goal for the "how we know we succeeded" section. :)

On the "LTS focus" bit, I agree, and wonder if we should even extend it to Frameworks and apps. Right now LTS distros that ship Plasma 5.12 have provided their users with a steady stream of bugfixes for Plasma, but their old versions of apps and Frameworks are full of known bugs that were fixed in subsequent versions, but not made available to their users because we don't provide easy LTS packaging and their packagers are too overworked to find and backport fixes manually.

CERN announced their Microsoft Alternatives project https://home.cern/news/news/computing/microsoft-alternatives-project-malt

This goal seems very in tune with theirs.

My suggestions for this proposal would be to focus it around Organizations which is far more general instead of Big Enterprise and change the "how would we know we succeeded" to something like "we see more distributions switch to Plasma as default" or something like that instead of naming specific ones. We have no control over whether a certain distribution picks Plasma because those choices are not just based on popularity or how good our software is - for example Red Hat is heavily involved in GNOME and I don't see them switching to Plasma even if a lot of people on a forum asked for it.

Organizations

Happy to find something else. For me organisation implies non-profit. Maybe "deployment"?

and change the "how would we know we succeeded"

It was intended somewhat jokingly. All goals are somewhat open ended and hard to really define an end point.
I don't want to say something about more distros as that doesn't convey anything about any intended focus.

> And possibly most importantly of all we need whitepapers of successful deployments flooding promo.

We can look for a few cases we already have, as you mention, CERN, also NASA, Sincrotron (we are actually working on an interview about the latter), public institutions in Barcelona... Yeah, I think that is doable.

In T11080#188569, @davidedmundson wrote:

Organizations

Happy to find something else. For me organisation implies non-profit. Maybe "deployment"?

I think organizations leaves it open ended and emphasises that it's about collaboration. Big Enterprise and deployment sound very focused on a kind of top-down commercial approach that isn't too concerned with the freedom for the users. KDE speaks to me because it's by real people and for real people and I think our goals should reflect things that help real people. I think there are way bigger things we should tackle in the KDE community than whether Google or Facebook start to use Plasma on their workstations for making surveillance software.

I like the benchmark

SLED and RHEL ship plasma out the box due to customer demand

... but does it actually reflect the goal "KDE for Big Enterprise"? Or let me paraphrase, do big enterprises actually use RHEL and SLED on workstations? What are the stats there?

Middle-sized and big enterprises are very much entrenched in the Microsoft ecosystem, at least here in Germany. From a specific company size upwards there's no escaping Office 365, Sharepoint, Exchange, MS Teams, Skype etc.

In T11080#189329, @martinsotirov wrote:

I like the benchmark

SLED and RHEL ship plasma out the box due to customer demand

... but does it actually reflect the goal "KDE for Big Enterprise"? Or let me paraphrase, do big enterprises actually use RHEL and SLED on workstations? What are the stats there?

I don't have hard numbers, but at my last employer, we sold commercial Linux software for a variety of *very* big enterprises (Mostly American, but a few German too) that use RHEL and Ubuntu internally. Maybe not for everything, but these companies had four and five figure Linux workstation deployments.

In T11080#189332, @ngraham wrote:

I don't have hard numbers, but at my last employer, we sold commercial Linux software for a variety of *very* big enterprises (Mostly American, but a few German too) that use RHEL and Ubuntu internally. Maybe not for everything, but these companies had four and five figure Linux workstation deployments.

Ok, that's nice to hear. When I consult bigger companies on site in Germany, so far I always see the same picture – Windows and MS services on every machine, maybe a couple of Linux desktops in IT. Server is of course a whole different story, but we're talking about the desktop here.

I'm not too familiar with massive deployment. What features do others OS/Desktop provide, is there a list ? Is LDAP the most important part missing ?
Linux is already tailored for massive deployment, it could become a solid candidate.
Would it be possible to do a list of what's already in place (system side/kde side) and what's missing ?
What about security, usually there is a mandatory antivirus and prohibition from running any not authorized application (like running a .exe from USB or installing an application). Can this slow KDE piecing the corporate market ?

I saw lots of RDP connection as a mean to provide applications / data in a secure way. Is that a good way to go in the enterprise ?

From what I see :

• easy user GUI integration in the office / enterprise environment (desktop vs laptop that you can bring home)
• provide scripting hooks to automate configuration of GUI elements (links on desktop, dolphin places, favorites applications, more ?) when connected to network
• remote loading of settings (network drives, printers & scanners, projectors ...) when logged in network (local or over vpn/wireguard)
• priority support for commercial subscribers ?
• policy enforcing ?

Also, I raised some issues in T11069 about the security of some KDE application. @dvratil wrote about certain applications running on legacy code and in my vocabulary, that mean unmaintained and dangerous.
I do know that CVE- are important for many business/organisation and quick response to CVE might be a important deciding factor.

The elephant in the room is that Big Enterprise currently relies on Windows mostly because of their reliance on software not available for Linux. The biggest ones are MS Exchange and Office, but also included would be Adobe's suite, AutoCAD, Maya/3Ds Max/Lightwave, Final Cut Pro, and so on.

I'm aware of a number of large deployments already that use Linux, but the common denominator is that their use cases don't have hard dependencies on software that you can't get on our platform so (e.g. elementary schools, scientific computing, web development). These kinds of deployments are probably the ones we should be targeting for conversion to Plasma, as well as some of the ones whose software dependencies can actually be wholly addressed by our professional-quality offerings (e.g. Krita, KDenlive).

This seems very focused on deployments, which is good in itself. Now with my "I work in dev services" hat on, I think the scope should be slightly extended to also encompassing the amount of people looking for KDE related services beyond deployments.

The success of the current Windows based ecosystem is also that development time goes into it because of user needs. In our case that'd create a virtuous circle where more developers would spend paid time on improving KDE software (including KDE Frameworks in the case of in-house business specific applications).

@ervin could you expand on what you mean. Especially in terms of actions we can undertake.

@jrioux

I don't have a solid list, but I've met with Munich people a bunch of times. I tried to list the sore points I knew of above.

I think your ideas are pretty much in line with what I had in mind with the exception of "commercial subscribers" which I think is a route we don't want to be thinking about.

In T11080#189875, @davidedmundson wrote:

@ervin could you expand on what you mean. Especially in terms of actions we can undertake.

I don't necessarily have actions in mind yet to be honest... well nothing beyond the "let's have a list of companies which can do KDE stuff". What I have in mind is more on the success criteria: it needs to also drive development business.

My worry is that otherwise it's "just deployments" which can be done in a way where some company basically slap KDE stuff on an install image but there's no investment in time or money into KDE itself. We had at least a deployment in France done in that fashion. I don't like those, because yes they bring user, but they mostly bring extra pressure on spread thin maintainers, I'd like something more sustainable.

Hope that clarifies.

Right, I fully understand what you're saying now, makes sense.

My optimistic side hopes it'll happen naturally, but it's definitely something we should keep in mind.

. well nothing beyond the "let's have a list of companies which can do KDE stuff".

AFAIK this now exists if some company contacts the board looking for development.

In T11080#189900, @davidedmundson wrote:

. well nothing beyond the "let's have a list of companies which can do KDE stuff".

AFAIK this now exists if some company contacts the board looking for development.

Ah but then it's not a public list, one has to contact the board? Because if it was meant to be public, somehow I couldn't find it last time I checked.

List is still being assembled. Will be public soon (TM). ;)

A few more thoughts on what large deployments may need or care about. Some of those have been mentioned already, some things already work just fine anyway and some others are outside of KDE scope IMHO:

• connect to directory service (usually LDAP, maybe also Active Directory)
• possibility to do deployment-wide custom preconfiguration (provide defaults or enforce settings)
  • including possibility to disable various features (e.g. functionality related to online services like twitter,...)
• "automatic" user-specific pre-configuration and setup (like setting up and assigning user-specific printers and network shares, automatic account setup in email client, menu entries,...), so things basically "just work" without the user having to take care of anything
• synchronisation of user-specific settings between multiple computers (with possibility to log in on multiple machines at the same time)
• system for easy mass-deployment of fully configured systems
• frontend for administrators to manage systems and possibility to easily administer systems remotely, without "having to be a Linux expert"
• "Core applications" (like browser, office suite and PDF viewer) usually play a crucial role.
• Business applications that might be platform-specific may be an issue, though that seems to improve as those are increasingly web apps (though old business applications are often around for very long)
• Proprietary document formats (like e.g. PDF documents using the proprietary and deprecated XFA technology) may be an issue.
• Option of official support (contracts) seem to be an important criterion for many large organizations (whom can they ask/"blame" if something doesn't work as expected).

IMHO, there's a part where KDE (and other projects) can support these enterprises/organizations in providing them with great and reliable software and support, and other parts where it's up to those enterprises/organizations to do their homework (like changing workflows and getting rid of obsolete technologies).

And IMHO, the usability and productivity initiative has already helped a lot in making KDE software more enterprise-ready! :-)

In T11080#192934, @michaelweghorn wrote:

A few more thoughts on what large deployments may need or care about. Some of those have been mentioned already, some things already work just fine anyway and some others are outside of KDE scope IMHO:

• connect to directory service (usually LDAP, maybe also Active Directory)
• possibility to do deployment-wide custom preconfiguration (provide defaults or enforce settings)
  • including possibility to disable various features (e.g. functionality related to online services like twitter,...)
• "automatic" user-specific pre-configuration and setup (like setting up and assigning user-specific printers and network shares, automatic account setup in email client, menu entries,...), so things basically "just work" without the user having to take care of anything
• synchronisation of user-specific settings between multiple computers (with possibility to log in on multiple machines at the same time)
• system for easy mass-deployment of fully configured systems
• frontend for administrators to manage systems and possibility to easily administer systems remotely, without "having to be a Linux expert"
• "Core applications" (like browser, office suite and PDF viewer) usually play a crucial role.
• Business applications that might be platform-specific may be an issue, though that seems to improve as those are increasingly web apps (though old business applications are often around for very long)
• Proprietary document formats (like e.g. PDF documents using the proprietary and deprecated XFA technology) may be an issue.
• Option of official support (contracts) seem to be an important criterion for many large organizations (whom can they ask/"blame" if something doesn't work as expected).
  
  IMHO, there's a part where KDE (and other projects) can support these enterprises/organizations in providing them with great and reliable software and support, and other parts where it's up to those enterprises/organizations to do their homework (like changing workflows and getting rid of obsolete technologies).
  
  And IMHO, the usability and productivity initiative has already helped a lot in making KDE software more enterprise-ready! :-)

In fact, I had a very enterprisey use case in mind for Okular as part of the U&P initiative (which you can see in T6831): filling out PDF forms, adding an image of your handwritten signature with the stamp annotation, and printing it out or emailing it to someone else in such a way that all the filled-in form data and the signature are preserved. The macOS Preview app makes all of these tasks trivially easy and 100% reliable. It even has a feature whereby you can use your computer's built-in camera to take a picture of your signature written on a piece of white paper, and it will store it internally so you can easily add it as a stamp when signing documents. Okular has all of these features already, but the UX and reliability are poorer.

...That's kind of a common theme, really. We already have most of the features, they're just not presented well enough, reliable enough, or polished enough for regular people to use them or businesses to feel comfortable relying on them.

IMHO most of your stuff is DE agnostic. And we implemented that with our config framework in Munich.
BTW: what kind of input are you KDE people actually seeking in this ticket? Just KDE specific stuff?

In T11080#192934, @michaelweghorn wrote:

• connect to directory service (usually LDAP, maybe also Active Directory)

What are you expecting here? Something like the group policies Windows defines? Otherwise LDAP / kerberos is completely handled on OS level. AD SSO works just fine, as you know (at least on sssd level). That LHM doesn't yet use SSO that much is a different problem.

• possibility to do deployment-wide custom preconfiguration (provide defaults or enforce settings)

IMHO that is more of a documentation problem. I didn't do anything in this area for the KDE4 => Plasma5 transition, but my impression was that it was rather hard to find information how to configure stuff with QML. AFAIK our reset script still just wipes some user config files, so the default will be restored.

• including possibility to disable various features (e.g. functionality related to online services like twitter,...)

That would be nice, like automatically disabled external data sources. I remember we patched khotstuff2, because of background images being literally too hot stuff for work. AFAIK we even added a firewall rule. Can't remember if it was also on Plasma5 or just kde4.

• "automatic" user-specific pre-configuration and setup (like setting up and assigning user-specific printers and network shares, automatic account setup in email client, menu entries,...), so things basically "just work" without the user having to take care of anything

I'm not sure what you expect here. We have ~ a hundred scripts, which pre-configure various applications on login before startkde runs and prepares the session for the user, mostly based on LDAP data. I tried to "free" our setup infrastructure multiple times over the years to no avail.

• synchronisation of user-specific settings between multiple computers (with possibility to log in on multiple machines at the same time)

That's also an OS feature. I don't want every DE to implement their own "roaming profile" implementation without a "mounted" home.

• system for easy mass-deployment of fully configured systems

There is spacewalk and landscape and cockpit. The latter are primary used for server management. I was told you can use spacewalk to distribute dconf settings. We do our stuff in LDAP and at the next login scripts will pick up changed values or new scripts.

• frontend for administrators to manage systems and possibility to easily administer systems remotely, without "having to be a Linux expert"

Now we can discuss what an "Linux expert" really is. But really this is also nothing on a KDE level IMHO.

• "Core applications" (like browser, office suite and PDF viewer) usually play a crucial role.

There is the general problem, that all the "major" programs like Firefox (via addon), LibreOffice (via extension), etc. have their own config "type". I know that LO also has a plugin to use AD Group Policies for config, but that won't work on all platforms. PDF is definitely a major pain, being it the viewers (okular) or generators / editors (LibreOffice).

IMHO most of this stuff is nothing specific to KDE, but "desktop management". And this area exposes a lot of NIH. Not that Munich helped in this regard , but at least we fix bugs upstream:-( I've seen multiple client rollouts. Everybody has basically the same client management requirements (applications, printers, mounts, (USB devices), roaming profiles, mobile devices) and starts from scratch. Some push their stuff to some shared code platform, but at that point they already have done some big investments, so no chance for something "common".

Just some bugs, out of my head:

• having a desktop link to a document on a share, which will freeze the whole DE with timeouts, if that share has access problems.
• KIO FUSE mount. Somebody started this a long time ago in extragears for KDE3, but it never matured or was even ported. Just like the .gvfs dir fuse mount, which exports GIO "mounts" to legacy apps (that is already mentioned in T6831).

Something else we learned: originally we used a lot of Kiosk stuff to "lock" settings, which made the experience "not so nice" for a user. Currently we just lock somehow security relevant settings. A lot is pre-configured but not locked. We also started with individual installs, but now just generate the KDE menu per user / group and install almost everything. This also drives the roaming profile handling in the background.

And a lot of more stuff. LiMux is almost 14.5y old now.

In T11080#192988, @jglogowski wrote:

IMHO most of your stuff is DE agnostic. And we implemented that with our config framework in Munich.

Yes, I totally agree. I don't expect KDE to take care of all of the mentioned aspects. That's what I was trying to say with "Some of those have been mentioned already, some things already work just fine anyway and some others are outside of KDE scope IMHO:". I still mentioned those, since I think many enterprises expect such features in order to consider migration to any Linux-based system, regardless of the desktop environment. Sorry in case that was off-topic here.

And while "SLED and RHEL ship plasma out the box due to customer demand." sounds like an ambitious goal, I think it would be great if many of those customers demanding it should demand it because they're migrating away from their current proprietary solutions.

In T11080#192934, @michaelweghorn wrote:

• connect to directory service (usually LDAP, maybe also Active Directory)

What are you expecting here? Something like the group policies Windows defines? Otherwise LDAP / kerberos is completely handled on OS level. AD SSO works just fine, as you know (at least on sssd level). That LHM doesn't yet use SSO that much is a different problem.

I didn't have any specific expectations here. I think I once heard that SDDM (or some SDDM themes) used to have issues with LDAP logins, but that may no longer be an issue now.
As for the other points you mention, I didn't really have any specific expectations for KDE to address specific issues.

IMHO most of this stuff is nothing specific to KDE, but "desktop management". And this area exposes a lot of NIH. Not that Munich helped in this regard , but at least we fix bugs upstream:-( I've seen multiple client rollouts. Everybody has basically the same client management requirements (applications, printers, mounts, (USB devices), roaming profiles, mobile devices) and starts from scratch. Some push their stuff to some shared code platform, but at that point they already have done some big investments, so no chance for something "common".

True, and the fact that it seems everybody seems to have to somewhat start from scratch may be a major hindrance in my opinion. Again, that's nothing I primarily expect KDE to "fix" in the first place, since most of this is DE-agnostic, as you say.

So far the description is still a bit short. Does anyone of you want to expand it some more and then move it to the next column so we can consider it for voting?

I see that so far the a discussion has revolved around the technical side of things. How about thinking a bit more on how we plan to reach out to these organizations? Can we form a strategy and start building collaborative relationships with them?

As a first step, we could for example approach a couple of these organizations that are already using KDE and start working together on understanding their needs and identifying real use cases and improvements that could be made to our software in order to match their requirements.

Having worked with these "early-adopters" and once we are confident with the status of our products, we could then devise a plan on reaching out to other organizations, using the previous cases as success stories to strengthen our position.

I also see this kind of initiatives as having the potential of enabling new contributor paths to our products from within the organizations.

Quick reminder that there are two days left before the voting starts. Please make any changes you still want to make soon.

You may find that implementing technical solutions is insufficient. You will also need a marketing and sales strategy (even though no actual sales will take place) to convince enterprises to adopt a different technology to what they already have. That a technology gets adopted due exclusively to its technical merits alone is something that rarely happens any more, even less so in businesses that are, by and large, notoriously conservative.

By the way, @davidedmundson, you could improve the title of your goal by making the endgame you have in mind more explicit in the title. Two suggestions could be:

• Increase adoption of KDE in Companies
• Make KDE Enterprise-ready

Depending on which one better fits what you are thinking of.

Something, we might at least consider: Is this an appropriate phase of the plasma 5 life cycle for this?
(I assume this is not a goal for a future plasma6?)

With Qt6 aiming for a release towards the end of 2020 (https://blog.qt.io/blog/2019/08/07/technical-vision-qt-6/), at some time in the next couple of years development for plasma and most apps is probably (?) going to focus on porting to Qt6, introducing new features (and bugs), code rewrites, breaking APIs, ... which is pretty much the opposite of this goal? Is this going to be a problem of conflicting interests?

And if the goal succeeds, and there are new large deployments of KDE software, any contribution back from these installations would happen to the Qt5 based versions of the KDE software? (If they ever do contribute back, that is :) )

If help is needed I am willing to support. I can also support the link to libbreoffice.

In addition I think it's not only large enterprises, thi initiative can be also useful for smaller companies.

I am thinking more like software as a service, where you can click and collect your linux server and linux clients.

For example you have an hardware company where you can select the full it infrastructure. Linux server with software x, y, ... x linux clients already preconfigured and connected to the server, so that you only have to login with the company mail address and everything is preconfigured.

Small enterprises use google apps cause they don't have to care about something. Login and done.

I would like to buy, sell an google chromebook with foss under your control, but with the power of all foss.

In T11080#192988, @jglogowski wrote:

• system for easy mass-deployment of fully configured systems

There is spacewalk and landscape and cockpit. The latter are primary used for server management. I was told you can use spacewalk to distribute dconf settings. We do our stuff in LDAP and at the next login scripts will pick up changed values or new scripts.

(Full disclosure: I am the Product Owner of SUSE Manager and by extension, of Uyuni)

Spacewalk is mostly stagnant since a few years ago, as Red Hat abandoned it in favor of Foreman, Katello and others for RH Satellite 6. SUSE forked SpaceWalk and is modernizing and enhancing it as Uyuni:
https://www.uyuni-project.org/
https://github.com/uyuni-project/

We have deployments of tens of thousands of desktops with the commercial version (SUSE Manager; Uyuni is essentially the same thing but without support and based on openSUSE instead of SUSE Linux Enterprise Server).

Is there any way KDE and Uyuni can collaborate? Let me know, join the mailing lists or create GitHub issues/RFCs.

Vote invite were sent to everyone subscribed to the KDE community mailing list and everyone with a developer account. Any contributor who didn't receive one please subscribe to the mailing list to not miss future announcements and send me a quick email (lydia@kde.org) and I'll send you a vote invite.

[spam comment removed by sysadmin]

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.

+1 to revive this goal

In T11080#277256, @fusionfuture wrote:

+1 to revive this goal

Feel free to take this into the next round of goals. I won't have time to lead it, but I feel you're a good candidate to do so.