So .. Bodega.

So, the code is hosted on git.kde.org .. it is a 'proper' KDE project. It is also not a "write a app store for a tablet" project. That was simply the first concrete use case for it.

Currently there is the server, the management UI (for uploading content, managing stores, etc) and a client written in QML. The server is pretty simple to get up and running (it's a node.js app that uses postgresql and redis, and that's about it), and I am more than happy to host KDE's instance because it not only keeps KDE out of possible legal issues but it offers the opportunity for a central place where many projects can collaborate on these things. openSuse is working on adopting it as well .. and with any luck this year we'll see more and more adoptees.

The benefits are many: each project would get its own "store" and the project maintainers would be able to both design the structure of the store (so, e.g., Plasma could have an area for desktop themes, another for Look & Feel packages, another for wallpapers, ...) and curate (if desired). Once can sell content, non-stupid ratings, user feedback, statistics, blah blah blah are all supported. It also is not limited to things like wallappers and themes; we already have the 40k+ books from project gutenberg and much more could be on the way.

Bodega honestly does everything necessary and then some to replace GHNS. I've looked at making a Bodega backend for KHotStuff (the library KDE applications use to access kde-look.org, etc.) and it looks completely possible, which would mean that all KDE applications could use a Bodega instance with zero porting. they would just need to adjust their ksnrc files to reflect that they are now using bodega @ <some server> instead of kde-look.org. so it could be a very nicely staged transition.

KDE e.V. took a vote in the last few months that passed overwhelmingly to commission a "how KDE can use Bodega" plan. I asked for this vote because there are both project and business issues. So there is already a mandate from the community to take this forward.

THAT said, the work that remains is:

* writing that KHotStuff backend (i'm willing to do this)

* porting the existing bodega client (and library) to Qt5 + QML2. the port to Qt5 will be easy, adapting it to QML2 will be a bit of work. Marco and I would probably take this on together

* pulling content from GHNS providers that applications currently rely on into a Bodega instance (should we care to .. this is about more than themes and what not: many KDE applications use it for a variety of things)

* designing a nice web client; this is something we haven't done yet because it really is not our speciality. a couple of plasma devs were working on it, but i don't know how far it has progressed, and they aren't really web devs. the good news is that Bodega communicates entirely using json (documented at https://apidocs.makeplaylive.com) , so a nice HTML5 web app should be within reach of any reasonably good web dev. upload and management of content already has a website (also HTML5-y, even) so that doesn't need doing; just browsing and downloading from the web

* deciding on some policies for KDE's bodega stores, e.g. is anonymous browsing and downloading ok? or should we require a log in for one, both, etc? i don't really care about what the decisions are, someone just needs to make them. (obviously uploading requires authentication; legal dragons lurk there)

* look into some way of synchronizing accounts with identity.kde.org? having an SSO of some form or another that isn't horrible / consist of random websites would be one possible answer.

I'm happy to host a meeting on G+ hangouts, irc, whatever... to discuss this further with those who are interested to develop a going forward plan.

I should add one other thing: designing and writing Bodega took ~2 years, and for a handful of those months I actually paid a couple people to focus on it full time. It is *not* a trivial problem to solve, so I would encourage people to use what is there rather than start from scratch. Also, I know of no other system out there that does anything even remotely similar that is Free software.

Aaron, perhaps it would be worthwhile to post this also to the community ML? Perhaps someone interested might show up.

Some form of SSO would definitely be desirable - integrating with Identity is currently complicated, especially for sites with their own user database and registration systems. This is something we want to implement across kde.org already, so I suggest we discuss this at some point.

einar wrote:Aaron, perhaps it would be worthwhile to post this also to the community ML? Perhaps someone interested might show up.

I've talked about Bodega so much and for so long in the KDE community with so little interest in return, that I have lost my motivation to continue promoting it within KDE. If KDE wants what Bodega offers, then someone will eventually step up.

I've offered in this thread to arrange an online meeting with people who are interested / motivated, and it looks like there are a few such people here, so who knows ...

bcooksley wrote:Some form of SSO would definitely be desirable - integrating with Identity is currently complicated, especially for sites with their own user database and registration systems. This is something we want to implement across kde.org already, so I suggest we discuss this at some point.

Absolutely; if you have already started looking at possible solutions, I'd be very interested in discussing ... OAuth simply looks broken and I'm really not informed enough on the topic to know where to turn beyond the popular-but-obviously-flawed options currently on the web.

aseigo wrote:I've talked about Bodega so much and for so long in the KDE community with so little interest in return, that I have lost my motivation to continue promoting it within KDE. If KDE wants what Bodega offers, then someone will eventually step up.

To be honest, what is a possible explanation is that, regardless of how many posts you made (FWIW, I've read most of your blog posts on Bodega myself), Bodega is seen as "Plasma Active's App Store". I don't think anyone's to blame, but with phones and tablets etc, it's a really entrenched way of thinking.

To be honest, what is a possible explanation is that, regardless of how many posts you made (FWIW, I've read most of your blog posts on Bodega myself), Bodega is seen as "Plasma Active's App Store"

For the record I never saw it that way. My thinking was along the lines of, 'Why the hell is plasma active getting a proper app store, and normal plasma is stuck with this c**p!?'.

Well, for what it's worth I'm very interested in seeing this happen. I was thinking today that not only would this be good for replacing the current GHNS theme / application plugin portal, but would open the gates to delivering other relevant application content, such as tutorials, videos, templates, podcasts etc. Which would be awesome.

My only concern would be how it is implemented on the desktop end as it could be seen to users as being a second app store, in addition to the main one that handles the updates etc, and I think that would be confusing to some. Unless it is written in such a way that apps like Muon can easily integrate it into themselves, so it would be one uniformed store? One to think about anyway.

Not sure how much use I can be in this process though as I can't program (well, I'm dabbling in python at the moment, but yeah..), but if you need someone to wax lyrical then I'm your guy.

Perhaps our lyrical waxing will do some good at the end of the day. Although I am wary of the technical requirements to fix this, it's one of those areas of KDE where I saw a ton of potential but, like everyone else, my inner-new-user cringed and fell off a mental cliff as soon as it failed to 'just work'.

In my opinion, even with the current system, there are some major things that could be improved. I feel that, if you need to visit a website to actually install the theme, it shouldn't show up in get hot new stuff. Themes should always install cleanly- no one should be confused when nothing happens, or be forced to learn about which directories themes are in on some third-party website.

If there are some themes, artwork, or plasma addons that can't be simply installed without manual intervention, we may need more features in the backend to support them. But, in general, it would help to present only automatic, easy options to users through these dialogs. A tag for 'manual installation' could help us avoid displaying these to users without removing any content from the website. Some curation and incentives for authors to provide functional, presentable work could improve things a lot. Of course, I don't think we should turn away contributions, but we can design the system to encourage submissions that provide a better browsing/installation experience.

aseigo wrote:I've talked about Bodega so much and for so long in the KDE community with so little interest in return, that I have lost my motivation to continue promoting it within KDE. If KDE wants what Bodega offers, then someone will eventually step up.

Just to provide some context for people in this thread who may wonder what Aaron is referring to: Presumably in addition to 1-on-1 talks with individual community members, Aaron started a discussion on the mailing list internal to KDE e.V. members, proposing that KDE could officially partner with MakePlayLive to use Bodega for its content platform, along with several different ideas on how to exactly proceed. It made sense to post it on that list, because of the "business issues" Aaron mentioned.
After some discussion, the KDE e.V. membership voted to task the board with driving plans for Bodega adoption forward (as Aaron already mentioned). Since then, however, nothing has happened yet (at least nothing we know about).

So this is explains why Aaron is slightly frustrated about something others in this thread may not even be aware of

That said, maybe those who have gathered in this thread can indeed push the idea forward.

Aaron, i'll mail you separately concerning the SSO suggestions we have at the moment.

davidwright wrote:For the record I never saw it that way. My thinking was along the lines of, 'Why the hell is plasma active getting a proper app store, and normal plasma is stuck with this c**p!?'.

+1

davidwright wrote:Well, for what it's worth I'm very interested in seeing this happen. I was thinking today that not only would this be good for replacing the current GHNS theme / application plugin portal, but would open the gates to delivering other relevant application content, such as tutorials, videos, templates, podcasts etc. Which would be awesome.

Again, my thoughts exactly. Right now there are wayyyy too many .org sub-domains for OpenDesktop.org (is there an official list on the web showing how many there actually are?). With no universal log-in across them all. Having one user experience to browse all relevant content would be ideal.

davidwright wrote:My only concern would be how it is implemented on the desktop end as it could be seen to users as being a second app store, in addition to the main one that handles the updates etc, and I think that would be confusing to some. Unless it is written in such a way that apps like Muon can easily integrate it into themselves, so it would be one uniformed store? One to think about anyway.

I was discussing with some of the Kubuntu Devs not long ago, and what I was thinking was something like using Muon Discover as the one-for-all user experience portal to all downloadable content. So in other words, what we would have under my vision would be that when launching Muon Discover the user would be presented with three tabs:

(1) The main Discover Tab, used exactly like it is now. That is, to find new cool software not included on the install media such as VLC, KMyMoney, etc.

(2) A KGHNS replacement tab, that behaves much like the main Discover tab but that would be for any content NOT considered an app. Thinks like:

• Plasmoids
• templates
• wallpapers
• icons
• Plasma themes
• color schemes
• etc

This could be entirely in HTML5 and use Bodega.

(3) An update tab, showing all available updates and giving the user the means to update their system

I also do like Aaron's idea a lot, BTW, and think that no mater what the backend needs ported to Bodega. There are too many problems with the aging technology used to get GHNS content and install it to list here, and I believe it's all been pretty well documented in the past. It just needs to happen.

Perhaps a project of the magnitude of this scale would be a perfect opportunity for a cross-distro collaboration between, say, Kubuntu, Suse, and Blue Systems, with resource support via the KDE Board? If something like the original system was implemented at one point in time, no reason to think it couldn't happen again. Especially with awesome tools like Aaron has been talking about now for ages...

Aaron - What would be your guess as to why the reluctancy on the Board's part so far? I'm mainly asking from the P.O.V. of ascertaining if the reasoning is of a scope-of-project nature, or a political one, or some combination of both.

*Bump* - Not much thought about KGHNS from a usability standpoint? That's somewhat surprising. Common' people - weigh in!

dequire wrote:*Bump* - Not much thought about KGHNS from a usability standpoint? That's somewhat surprising. Common' people - weigh in!

The issue currently feels kinda "blocked" by the whole kde-look vs. Bodega issue, in which nothing has moved yet. I personally don't see much use in discussing UI details unless we know which platform with which capabilities will be used. That's just my personal opinion, though. I won't keep anyone from continuing the brainstorm even before that issue is sorted out.

In other words, for this to move forward someone needs to do some work (test install of Bodega etc.) to see if it fares as a replacement (likely it is) and how use its API for GHNS (this is probably the hardest part).