== App Developer Week -- Publishing Your Apps in the Software Center: the MyApps Portal -- Anthony Lenton -- Tue, Sep 6th, 2011 == {{{#!irc [19:00] ok, I guess that's me :) [19:01] Hi everybody, I'm Anthony Lenton [19:01] I work at Canonical, in ISD. We're the team responsible for the development of Ubuntu SSO, Ubuntu Pay, and quite a few other smaller infrastructure-related systems [19:01] Within ISD I'm leading the team that is in charge of the Software Center Server === Andy80-Owl is now known as Andy80 [19:02] that includes ratings and reviews, the software center agent, and the MyApps portal [19:02] ... for those of you that are unfamiliar with the MyApps portal, it's what sits at https://myapps.developer.ubuntu.com/ [19:02] we're currently in public beta, so you can create an account and play around with it [19:02] (please let us know what breaks! :) ) [19:03] also, apologies up front if I incorrectly call MyApps "the devportal" or "the developer portal" [19:03] We started clalling it that during development, hence the name of the project on Launchpad, https://launchpad.net/developer-portal [19:04] Clearly *the* developer portal is developer.ubuntu.com, this awesome bucket of knowledge dpm and johnoxton are going to tell us all about right here on Thursday at 16UTC [19:04] MyApps is the part of developer.ubuntu.com that takes care of the submission workflow to get your apps published in the Ubuntu Software Center [19:04] so... my plan is to tell you a bit of the story of MyApps, and go over the current workflow [19:05] then tell you a bit about the most immediate milestones in our roadmap, and answer a few questions [19:05] (yay, none so far :) ) [19:06] We started with myapps after UDS-N, end of last year-ish, as a way to make it easier for developers to get their (paid) apps into USC [19:06] we had already had for-purchase apps in USC for just over six months by then [19:06] and we still had only a bunch of (not quite 10 iirc) apps available for purchase [19:07] Adding new apps was a painfully manual process, for all parts involved. [19:07] Contacting and arranging an agreement with the developer was done manually, they'd send us the app somehow and we'd manually package it up [19:07] A sysadmin would then manually make it available for sale. Canonical's finance department would get a monthly report of sales and (manually!) send developers the right amount of money [19:08] We knew if we wanted to make this scale to tens of thousands of apps, we would need to remove all or as many as possible of the manual steps in this process. [19:09] so, what's up on https://myapps.developer.ubuntu.com/ is what we currently have. There's still quite a few of manual pieces involved [19:09] but the plan is to get it fully automated in the future [19:09] Once you've created an account and accepted the terms of service on that site, you can go straight in and submit an application for review [19:10] (not sure if it's best for you to do that now, this was going to be a more of a hands-on session but in the end it's more of a talk-and-screenshots session :) ) [19:10] anyway... [19:10] The submission workflow currently has five steps (or six, depending on how you count) [19:11] - basic details of your app (name, tagline, price, and upload the actual code) [19:11] - Finding your app (description, keywords, and in which USC department it belongs) [19:11] ( USC is Ubuntu Software Center there ^) [19:11] - Showing your app (Screenshot and icons) [19:12] - License and support (Type of license and support url) [19:12] (Ok, yes, these had no real reason to be together in the workflow) [19:12] - Getting paid (your paypal email, phone number and a postal address for contacting you at) [19:13] After that, the sixth step would be to just check the details and submit the app for review. [19:13] bulldog98 asked: when will it be possible to use a Qt based SSO [19:14] bulldog98: hm you mean like the current ubuntu-sso-client that's gtk only? I don't know of a project that does that [19:14] bulldog98: sso provides an api, the current gtk client was developed by U1 because it suited them best, but you can also use the API directly [19:16] bulldog98: I'm not sure how the different bits ussoc does would map to Qt, but it shouldn't be impossible to write such a client at the moment already [19:16] bulldog98: but I'm afraid I don't know of a project for doing that atm [19:16] shazzner75 asked: Any chance for alternate payment methods? Google Checkout, etc? [19:17] shazzner75: for purchasing apps, or for paying developers? there are plans to add new payment methods for both, but a bit longer term :) [19:18] not sure if Google Checkout is on the roadmap [19:18] anyway, this is what you'd see when you finish providing the details for your app: [19:18] http://ubuntuone.com/6FfqFGgGnNucVS6PiBma7T [19:19] When you submit an app for review, application reviewers are notified via email currently. They'll pick it up pretty soon [19:19] Packaging the app is still carried out manually at the moment [19:20] Though as jml mentioned yesterday, we're working on integrating pkgme that should automate most of that process [19:20] Once the application has been reviewed and uploaded we do some basic QA to ensure that, if it's made public, purchases will go smoothly and the app will launch successfully when installed. [19:21] This isn't intended to be QA of the application itself (beyond checking that some app actually launches), though very often we get feedback on the app itself during QA. [19:21] If at any point the reviewer has some question, or there's some missing bit of information in the app, the app will be passed back to the developer as "Needs Information". You can then modify your app with the right information, and resubmit for review [19:22] You can always see the full review feedback history for an app in the "Feedback" tab [19:22] (screenshot coming...) [19:22] http://ubuntuone.com/3bVuC7ZqIGEtTiXpe65zBb [19:22] So, assuming the application passes review, the app is *still* not automatically published in USC. [19:22] It's flagged as "Ready to publish", and you (the developer) can then decide when it actually goes public. [19:23] http://ubuntuone.com/7b97CAI3581sVHg6XpIHw8 [19:23] When the developer clicks "Publish" it's made public immediately, except for caching in the api and USC. [19:23] But it'll be really live and out there in USC worldwide in a few minutes. [19:24] The developer can also decide to unpublish an app at will once it's made public. This will remove the application from USC immediately so taht nobody else can purchase it [19:24] Users that have already purchased *will* still be able to download and/or reinstall the app. [19:24] Also, at any point, you can look at the sales information for your app in the "Metrics" tab [19:24] http://ubuntuone.com/0bbI5tMJ11HSnWJOooxk5N [19:25] So... upcoming features and things we're working on: [19:25] - Reviewer notes! At the moment you can't provide notes for the application reviewer along with the app [19:25] yep, silly, but we're on it :) [19:26] - pkgme integration. This is the automated packaging that jml went into details about yesterday. [19:26] That'll be *great* to have as packaging the app is one honking big piece of manual work that's still necessary [19:26] and we need to rely on the developer to provide packaging files, or the reviewer has to create them from scratch every time [19:27] - ARB integration. In the future free (libre and gratis) apps that are currently being reviewed by the Application Review Board will also be submitted through MyApps. [19:27] This will make things clearer, simpler and generally better for developers as you'll have a single place to submit your apps for publishing in USC. [19:28] Stay tuned for stgraber's session about the ARB, coming up next :) [19:28] yeah! [19:28] :D [19:29] - license key infrastructure. ... [19:29] this is almost a topic for another talk, but in a nutshell, you'll be able to provide batches of keys for your app [19:29] those will be served up one per purchase, and stored in a file locally for your application to check [19:30] shazzner75 asked: how do updates work? ie. developer pushes out new version, will it be available immediately or next Ubuntu cycle? What about free/libre apps? [19:30] shazzner75: so, we're still figuring out some of the details, but you don't need to wait for the next Ubuntu cycle [19:31] I mean, new versions are easier: they go through review as usual, and as soon as the reviewer uploads the fix, anybody that's purchased the app will get the update with the next batch of updates [19:32] when a new Ubuntu cycle comes along, the app will be repackaged for this new distroseries, and uploaded, so people that have purchased the app should still have it when they upgrade [19:33] (the bit that's tricky is apps that work in one version of Ubuntu but not in the next. currently those users will be update-less until the app is fixed for the new release) [19:34] wow, and that's about it. [19:35] so, the upcoming plan is to fix bugs, polish and add awesomeness. [19:35] be sure to tune in for dpm's and johnoxton's session on Thursday about the general developer.ubuntu.com portal [19:35] ...and jpugh's session on Friday for any questions about the business side of things. [19:36] Questions? [19:37] shazzner75 asked: Can you specify things like system requirements? (like for 3d games) [19:38] shazzner75: so, currently the only way to do this is to include a debian control file with your code [19:39] shazzner75: the grand plan is to allow you to do that in a friendlier way that works well with pkgme [19:39] so pkgme will "guess" your system dependencies [19:39] ah, you mean *system* dependencies [19:39] hm... :) [19:40] not that I know of, not currently, but that would be quite interesting [19:40] I mean, software-center would need to perform the checks on the user's box, but it would make sense [19:41] shazzner75: right, as in "at least so much RAM", or "these graphic cards aren't supported" [19:41] shazzner75: so far we've seen comments about system requirements in the application descriptions [19:42] shazzner75: but the system doesn't allow you to specify those in a more structured manner I'm afraid [19:42] (...yet! :) ) [19:45] shazzner75 asked: since I'm asking questions here, is there any policy about android-like usage of user-data or resources? (notifications, email, connects to web, etc) [19:46] shazzner75: I'm not really aware of the android policy... I'd pop that question at jpugh on his Friday session [19:49] shazzner75 asked: another question, apologies if this has been answered, when submitting a proprietary app. So you submit it as a binary (like jar file) or as source code to be packaged? [19:50] shazzner75: it hasn't been answered, and thanks for asking :) [19:50] There are 10 minutes remaining in the current session. [19:50] shazzner75: you can submit it as a binary (jar file, elf or whatever), no need to submit the source code [19:51] shazzner75: for proprietary apps that is [19:51] shazzner75: for libre apps going in for ARB review I imagine they'll expect to see the source code available :) [19:55] There are 5 minutes remaining in the current session. [19:56] ok, I think we're done then. thanks everybody for joining! stay tuned for stgraber, coming up next, don't go far :) }}}