Services Collaborating Openly at Akademy 2017
At the recently concluded Akademy 2017 in the incredibly hot but lovely Almería, yours truly went and did something a little silly: Submitted both a talk (which got accepted) and hosted a BoF, both about Open Collaboration Services, and the software stack which KDE builds to support that API in the software we produce. The whole thing was amazing. A great deal of work, very tiring, but all 'round amazing. I even managed to find time to hack a little bit on Calligra Gemini, which was really nice.
This blog entry collects the results from the presentation and the BoF. I realise this is quite long, but i hope that you stick with it. In the BoF rundown, i have highlighted the specific results, so hopefully you'll be able to skim-and-detail-read your specific interest areas ;)
The intention of the presentation was to introduce the idea that just because we are making Free software, that does not mean we can survive without money. Consequently, we need some way to feed funds back to the wildly creative members of our community who produce the content you can find on the KDE Store. To help work out a way of doing this in a fashion that fits in with our ideals, described by the KDE Vision, i laid out what we want to attempt to achieve in five bullet points, tongue-in-cheek called Principia pene Premium, or the principles of almost accidental reward:
Not pay-for-content alludes to the fact that we don't want to encourage paywalls. The same way we make our software available under Free licenses of various types, we want to encourage the creators of the content used in it to release their work in similarly free ways.
Easy means easy for our creators, as well as the consumers of the content they produce. We don't want either them to have to jump through hoops to receive the funds, or to send it.
Predictable means that we want it to be reasonably predictable for those who give funds out to the creators. If we can ensure that there are stable outgoings for them, say some set amount each month or year, then it makes it easier to budget, and not have to worry. Similarly, we want to try and make it reasonably predictable for our creators, and this is where the suggestion about Liberapay made by several audience members comes in, and i will return to this in the next section.
Finally, perhaps the most core concept here is that we want to make it possible to almost (but not quite) accidentally send one of the creators funds. Almost, because of course we don't want to actually do so accidentally. If that were the case, the point of being predictable would fly right out the window. We do, however, want to make it so easy that it is practically automatically done.
All of this put together brings us to the current state of the KDE Store's financial support system: Plings. These are an automatic repayment system, which the store handles for every creator who has added PayPal account information to their profile. It is paid out monthly, and the amount is based on the Pling Factor, which is (at the time of writing) a count of how many downloads the creator has accumulated over all content items over course of the month, and each of those is counted as $0.01 USD.
Content from alternate locations was the first item to be mentioned, which suggests a slight misunderstanding about the framework's abilities. The discussion revealed that what was needed was less a question of being able to replace existing sources in various applications, so much as needing the ability to control the access to KNewStuff more granularly. Specifically, being able to enable/disable specific sources was highlighted, perhaps through using Kiosk. It might still make sense to be able to overlay sources - one example given was the ability to overlay the wallpapers source (used in Plasma's Get New Wallpapers) with something pointing to a static archive of wallpapers (so users might be able to get a set of corporate-vetted backgrounds, rather than just one). This exact use case should already be possible, simply by providing a static XML source, and then replacing the wallpapers.knsrc file normally shipped by Plasma with another, pointing to that source.
A more complete set of Qt Quick components was requested, and certainly this would be very useful. As it stands, the components are very minimal and really only provide a way to list available items, and install/update/remove them. In particular two things were pointed out: There is no current equivalent of KNS3::Button in the components, and further no Kiosk support, both of which were mentioned as highly desired by the Limux project.
Signing and Security was highlighted as an issue. Currently, KNSCore::Security exists as a class, however it is marked as "Do not use, non-functional, internal and deprecated." However, it has no replacement that i am myself aware of, and needs attention by someone who, well, frankly knows anything of actual value about signing. OCS itself has the information and KNS does consume this and make it available, it simply seems to not be used by the framework. So, if you feel strongly about signing and security issues, and feel like getting into KNewStuff, this is a pretty good place to jump in.
Individual download item install/uninstall was mentioned as well, as something which would be distinctly useful for many things (as a simple example, you might want more than one variant of a wallpaper installed). Right now, Entries are marked as installed when one download item is installed, and uninstalling implicitly uninstalls that download item. There is a task on the KNewStuff workboard which has collected information about how to adapt the framework to support this.
But KNewStuff wasn't the only bit to get some attention. Our server-side software stack had a few comments along the way as well.
One was support for Liberapay which is a way to distribute monetary wealth between people pretty much automatically, which fits very nicely into the vision of creator support put forward in my presentation. In short, what it allows us to do
One topic which comes up regularly is adding support for the upload part of the OCS API to our server-side stack. Now, the reason for this lack is not that simply adding that is difficult at all, because it certainly isn't - quite the contrary, the functionality practically exists already. The problem here is much more a case of vetting: How do we ensure that this will not end up abused by spammers? The store already has spam entries to be handled every day, and we really want to avoid opening up a shiny, new vector for those (insert your own choice of colloquialism here) spammers to send us things we want to not have on the store. Really this deserves a write-up of its own, on account of the sheer scope of what might be done to alleviate the issues, but what we spoke about essentially came down the following:
For OCS itself, adding mimetype as an explicit way to search and filter entries and downloaditems was suggested. As it stands, it could arguably be implemented by clients and servers, however having it explicitly stated in the API would seem to make good sense.
The proposal to add tagging support to OCS currently awaiting responses on the OCS Webserver phabricator was brought up. In short, while there are review requests open for adding support for the proposal to Attica and KNewStuff respectively, the web server needs the support added as well, and further the proposal itself needs review by someone who is not me. No-one who attended the BoF felt safe in being able to review this in any sensible way, and so: If you feel like you are able to help with this, please do take part and make comments if you think something is wrong.
Finally, both at the BoF and outside of it, one idea that has been kicked around for a while and got some attention was the idea of being able to easily port and share settings between installations of our software. To be able to store some central settings remotely, such as wallpaper, Plasma theme and so on, and then apply those to a new installation of our software. OCS would be able to do this (using its key/value store), and what is needed here is integration into Plasma. However, as with many such things, this is less a technical issue (we have most of the technology in place already), and more a question of design and messaging. Those of you who have ever moved from one Windows 10 installation to another using a Microsoft account will recognise the slightly chilling feeling of the sudden, seemingly magical appearance of all your previous settings on the machine. As much as the functionality is very nifty, that feeling is certainly not.
This blog entry collects the results from the presentation and the BoF. I realise this is quite long, but i hope that you stick with it. In the BoF rundown, i have highlighted the specific results, so hopefully you'll be able to skim-and-detail-read your specific interest areas ;)
First, A Thank You In Big Letters
Before we get to that, though, i thought i'd quickly touch on something which i've seen brought up about what the social media presence of the attendees looks like during the event: If you didn't know better, you might imagine we did nothing but eat, party and go on tours. My personal take on that is, we post those pictures to say thank you to the amazing people who provide us with the possibility to get together and talk endlessly about all those things we do. We post those pictures, at least in part, because a hundred shots of a group of people in an auditorium get a bit samey, and while the discussions are amazing, and the talks are great, they don't often make for exciting still photography. Video, however, certainly does that, and those, i hear, are under way for the presentations, and the bof wrapups are here right now :) |
| Nothing will stop our hackers. And this is before registration and the first presentation! |
Presenting Presentations
Firstly, it felt like the presentation went reasonably well, and while i am not able to show you the video, i'll give you a quick run-down of the main topic covered in it. Our very hard working media team is working on the videos at the moment, though, so keep your eyes on the KDE Community YouTube channel to catch those when they're released.The intention of the presentation was to introduce the idea that just because we are making Free software, that does not mean we can survive without money. Consequently, we need some way to feed funds back to the wildly creative members of our community who produce the content you can find on the KDE Store. To help work out a way of doing this in a fashion that fits in with our ideals, described by the KDE Vision, i laid out what we want to attempt to achieve in five bullet points, tongue-in-cheek called Principia pene Premium, or the principles of almost accidental reward:
- Financial support for creators
- Not pay-for-content
- Easy
- Predictable
- Almost (but not quite) accidental
Not pay-for-content alludes to the fact that we don't want to encourage paywalls. The same way we make our software available under Free licenses of various types, we want to encourage the creators of the content used in it to release their work in similarly free ways.
Easy means easy for our creators, as well as the consumers of the content they produce. We don't want either them to have to jump through hoops to receive the funds, or to send it.
Predictable means that we want it to be reasonably predictable for those who give funds out to the creators. If we can ensure that there are stable outgoings for them, say some set amount each month or year, then it makes it easier to budget, and not have to worry. Similarly, we want to try and make it reasonably predictable for our creators, and this is where the suggestion about Liberapay made by several audience members comes in, and i will return to this in the next section.
Finally, perhaps the most core concept here is that we want to make it possible to almost (but not quite) accidentally send one of the creators funds. Almost, because of course we don't want to actually do so accidentally. If that were the case, the point of being predictable would fly right out the window. We do, however, want to make it so easy that it is practically automatically done.
All of this put together brings us to the current state of the KDE Store's financial support system: Plings. These are an automatic repayment system, which the store handles for every creator who has added PayPal account information to their profile. It is paid out monthly, and the amount is based on the Pling Factor, which is (at the time of writing) a count of how many downloads the creator has accumulated over all content items over course of the month, and each of those is counted as $0.01 USD.
 |
| Space-age looking crazy things at the Almería Solar Platform. Amazing place. Wow. So science. |
Birds of a Feather Discuss Together
On Wednesday, a little while before lunch, it was time for me to attend my final BoF session of the week (as i would be leaving early Thursday). This one was slightly different, of course, because i was the host. The topic was listed as Open Collaboration Service 1.7 Preparation, but ended up being more of a discussion of what people wanted to be able to achieve with the store integration points we have available.
Most of the items which were identified were points about KNewStuff, our framework designed for easy integration of remote content using either OCS, or static sources (used by e.g. KStars for their star catalogues).
A more complete set of Qt Quick components was requested, and certainly this would be very useful. As it stands, the components are very minimal and really only provide a way to list available items, and install/update/remove them. In particular two things were pointed out: There is no current equivalent of KNS3::Button in the components, and further no Kiosk support, both of which were mentioned as highly desired by the Limux project.
Signing and Security was highlighted as an issue. Currently, KNSCore::Security exists as a class, however it is marked as "Do not use, non-functional, internal and deprecated." However, it has no replacement that i am myself aware of, and needs attention by someone who, well, frankly knows anything of actual value about signing. OCS itself has the information and KNS does consume this and make it available, it simply seems to not be used by the framework. So, if you feel strongly about signing and security issues, and feel like getting into KNewStuff, this is a pretty good place to jump in.
Individual download item install/uninstall was mentioned as well, as something which would be distinctly useful for many things (as a simple example, you might want more than one variant of a wallpaper installed). Right now, Entries are marked as installed when one download item is installed, and uninstalling implicitly uninstalls that download item. There is a task on the KNewStuff workboard which has collected information about how to adapt the framework to support this.
But KNewStuff wasn't the only bit to get some attention. Our server-side software stack had a few comments along the way as well.
One was support for Liberapay which is a way to distribute monetary wealth between people pretty much automatically, which fits very nicely into the vision of creator support put forward in my presentation. In short, what it allows us to do
One topic which comes up regularly is adding support for the upload part of the OCS API to our server-side stack. Now, the reason for this lack is not that simply adding that is difficult at all, because it certainly isn't - quite the contrary, the functionality practically exists already. The problem here is much more a case of vetting: How do we ensure that this will not end up abused by spammers? The store already has spam entries to be handled every day, and we really want to avoid opening up a shiny, new vector for those (insert your own choice of colloquialism here) spammers to send us things we want to not have on the store. Really this deserves a write-up of its own, on account of the sheer scope of what might be done to alleviate the issues, but what we spoke about essentially came down the following:
- Tight control of who can upload, so people have to manually be accepted by an administration/editors team as uploaders before they are given the right to do so through the API. In essence, this would be possible through establishing a network of trust, and through people using the web interface first. As we also want people to approach without necessarily knowing people who know people, a method for putting yourself up for API upload permission approval will also be needed. This might possibly be done through setting a requirement for people who have not yet contributed in other ways to do so (that is, upload some content through the web first, and then request api upload access). Finally, since we already have a process in place for KDE contributors, matching accounts with KDE commit access might also be another way to achieve a short-cut (you already have access to KDE's repositories, ability to publish things on the store would likely not be too far a stretch).
- Quality control of the content itself. This is something which has been commented on before. Essentially, it has been discussed that having linting tools that people can use locally before uploading things would be useful (for example, to ensure that a kpackage for a Plasma applet is correct, or that a wallpaper is correctly packaged, or that there is correct data in a Krita brush resource bundle, or that an AppImage or Flatpak or Snap is what it says it is, just to mention a few). These tools might then also be used on the server-side, to ensure that uploaded content is correctly packaged. In the case of the API, what might be done is to return the result of such a process in the error message field of a potentially failed OCS content/add or content/edit call, which then in turn would be something useful to present to the user (in place of a basic "sorry, upload failed" message).
For OCS itself, adding mimetype as an explicit way to search and filter entries and downloaditems was suggested. As it stands, it could arguably be implemented by clients and servers, however having it explicitly stated in the API would seem to make good sense.
The proposal to add tagging support to OCS currently awaiting responses on the OCS Webserver phabricator was brought up. In short, while there are review requests open for adding support for the proposal to Attica and KNewStuff respectively, the web server needs the support added as well, and further the proposal itself needs review by someone who is not me. No-one who attended the BoF felt safe in being able to review this in any sensible way, and so: If you feel like you are able to help with this, please do take part and make comments if you think something is wrong.
Finally, both at the BoF and outside of it, one idea that has been kicked around for a while and got some attention was the idea of being able to easily port and share settings between installations of our software. To be able to store some central settings remotely, such as wallpaper, Plasma theme and so on, and then apply those to a new installation of our software. OCS would be able to do this (using its key/value store), and what is needed here is integration into Plasma. However, as with many such things, this is less a technical issue (we have most of the technology in place already), and more a question of design and messaging. Those of you who have ever moved from one Windows 10 installation to another using a Microsoft account will recognise the slightly chilling feeling of the sudden, seemingly magical appearance of all your previous settings on the machine. As much as the functionality is very nifty, that feeling is certainly not.
 |
| Solar powered sun-shade platform outside the university building. With fancy steps. And KDE people on top ;) |
Another Thank You, and a Wish
Akademy is not the only event KDE hosts, and very soon there is going to be another one, in Randa in the Swiss alps, this year about accessibility. I will not delve into why this topic is so important, and can only suggest you read the article describing it. It has been my enormous privilege to be a part of that several years, and while i won't be there this year, i hope you will join in and add your support.
The word of the day is: Aircon. Because the first night at the Residencia Civitas the air conditioning unit in the room i shared with Scarlett Clark did not work, making us very, very happy when it was fixed for the second night ;)
The word of the day is: Aircon. Because the first night at the Residencia Civitas the air conditioning unit in the room i shared with Scarlett Clark did not work, making us very, very happy when it was fixed for the second night ;)
posted by leinir at 8/17/2017 01:46:00 pm
0 Comments:
Post a Comment
<< Home