Posts tagged with 'projects'

Late last year Amazon introduce a new EC2 image customized for Machine Learning (ML) workloads. To make things easier for data scientists and researchers, Amazon worked on including a selection of ML libraries into these images so they wouldn’t have to go through the process of downloading and installing them (and often times building them) themselves.

But while this saved work for the researchers, it was no small task for Amazon’s engineers. To keep offering the latest version of these libraries they had to repeat this work every time there was a new release , which was quite often for some of them. Worst of all they didn’t have a ready-made way to update those libraries on instances that were already running!

By this time they’d heard about Snaps and the work we’ve been doing with them in the cloud, so they asked if it might be a solution to their problems. Normally we wouldn’t Snap libraries like this, we would encourage applications to bundle them into their own Snap package. But these libraries had an unusual use-case: the applications that needed them weren’t mean to be distributed. Instead the application would exist to analyze a specific data set for a specific person. So as odd as it may sound, the application developer was the end user here, and the library was the end product, which made it fit into the Snap use case.

To get them started I worked on developing a proof of concept based on MXNet, one of their most used ML libraries. The source code for it is part C++, part Python, and Snapcraft makes working with both together a breeze, even with the extra preparation steps needed by MXNet’s build instructions. My snapcraft.yaml could first compile the core library and then build the Python modules that wrap it, pulling in dependencies from the Ubuntu archives and Pypi as needed.

This was all that was needed to provide a consumable Snap package for MXNet. After installing it you would just need to add the snap’s path to your LD_LIBRARY_PATH and PYTHONPATH environment variables so it would be found, but after that everything Just Worked! For an added convenience I provided a python binary in the snap, wrapped in a script that would set these environment variables automatically, so any external code that needed to use MXNet from the snap could simply be called with /snap/bin/mxnet.python rather than /usr/bin/python (or, rather, just mxnet.python because /snap/bin/ is already in PATH).

I’m now working with upstream MXNet to get them building regular releases of this snap package to make it available to Amazon’s users and anyone else. The Amazon team is also seeking similar snap packages from their other ML libraries. If you are a user or contributor to any of these libraries, and you want to make it easier than ever for people to get the latest and greatest versions of them, let’s get together and make it happen! My MXNet example linked to above should give you a good starting point, and we’re always happy to help you with your snapcraft.yaml in #snapcraft on rocket.ubuntu.com.

If you’re just curious to try it out ourself, you can download my snap and then follow along with the MXNet tutorial, using the above mentioned mxnet.python for your interactive python shell.

The Ubuntu Core Apps project has proven that the Ubuntu community is not only capable of building fantastic software, but they’re capable of the meeting the same standards, deadlines and requirements that are expected from projects developed by employees. One of the things that I think made Core Apps so successful was the project management support that they all received from Alan Pope.

Project management is common, even expected, for software developed commercially, but it’s just as often missing from community projects. It’s time to change that. I’m kicking off a new personal[1] project, I’m calling it the Ubuntu Incubator.

The purpose of the Incubator is to help community projects bootstrap themselves, obtain the resources they need to run their project, and put together a solid plan that will set them on a successful, sustainable path.

To that end I’m going to devote one month to a single project at a time. I will meet with the project members regularly (weekly or every-other week), help define a scope for their project, create a spec, define work items and assign them to milestones. I will help them get resources from other parts of the community and Canonical when they need them, promote their work and assist in recruiting contributors. All of the important things that a project needs, other than direct contributions to the final product.

I’m intentionally keeping the scope of my involvement very focused and brief. I don’t want to take over anybody’s project or be a co-founder. I will take on only one project at a time, so that project gets all of my attention during their incubation period. The incubation period itself is very short, just one month, so that I will focus on getting them setup, not on running them. Once I finish with one project, I will move on to the next[2].

How will I choose which project to incubate? Since it’s my time, it’ll be my choice, but the most important factor will be whether or not a project is ready to be incubated. “Ready” means they are more than just an idea: they are both possible to accomplish and feasible to accomplish with the person or people already involved, the implementation details have been mostly figured out, and they just need help getting the ball rolling. “Ready” also means it’s not an existing project looking for a boost, while we need to support those projects too, that’s not what the Incubator is for.

So, if you have a project that’s ready to go, but you need a little help taking that first step, you can let me know by adding your project’s information to this etherpad doc[3]. I’ll review each one and let you know if I think it’s ready, needs to be defined a little bit more, or not a good candidate. Then each month I’ll pick one and reach out to them to get started.

Now, this part is important: don’t wait for me! I want to speed up community innovation, not slow it down, so even if I add your project to the “Ready” queue, keep on doing what you would do otherwise, because I have no idea when (or if) I will be able to get to yours. Also, if there are any other community leaders with project management experience who have the time and desire to help incubate one of these project, go ahead and claim it and reach out to that team.

[1] While this compliments my regular job, it’s not something I’ve been asked to do by Canonical, and to be honest I have enough Canonical-defined tasks to consume my working hours. This is me with just my community hat on, and I’m inclined to keep it that way.

[2] I’m not going to forget about projects after their month is up, but you get 100% of the time I spend on incubation during your month, after that my time will be devoted to somebody else.

[3] I’m using Etherpad to keep the process as lightweight as possible, if we need something better in the future we’ll adopt it then.

Ever since we started building the Ubuntu SDK, we’ve been trying to find ways of bringing the vast number of Android apps that exist over to Ubuntu. As with any new platform, there’s a chasm between Android apps and native apps that can only be crossed through the effort of porting.

There are simple solutions, of course, like providing an Android runtime on Ubuntu. On other platforms, those have shown to present Android apps as second-class citizens that can’t benefit from a new platform’s unique features. Worse, they don’t provide a way for apps to gradually become first-class citizens, so chasm between Android and native still exists, which means the vast majority of apps supported this way will never improve.

There are also complicates solutions, like code conversion, that try to translate Android/Java code into the native platform’s language and toolkit, preserving logic and structure along the way. But doing this right becomes such a monumental task that making a tool to do it is virtually impossible, and the amount of cleanup and checking needed to be done by an actual developer quickly rises to the same level of effort as a manual port would have. This approach also fails to take advantage of differences in the platforms, and will re-create the old way of doing things even when it doesn’t make sense on the new platform.

NDR takes a different approach to these, it doesn’t let you run our Android code on Ubuntu, nor does it try to convert your Android code to native code. Instead NDR will re-create the general framework of your Android app as a native Ubuntu app, converting Activities to Pages, for example, to give you a skeleton project on which you can build your port. It won’t get you over the chasm, but it’ll show you the path to take and give you a head start on it. You will just need to fill it in with the logic code to make it behave like your Android app. NDR won’t provide any of logic for you, and chances are you’ll want to do it slightly differently than you did in Android anyway, due to the differences between the two platforms.

To test NDR during development, I chose the Telegram app because it was open source, popular, and largely used Android’s layout definitions and components. NDR will be less useful against apps such as games, that use their own UI components and draw directly to a canvas, but it’s pretty good at converting apps that use Android’s components and UI builder.

After only a couple days of hacking I was able to get NDR to generate enough of an Ubuntu SDK application that, with a little bit of manual cleanup, it was recognizably similar to the Android app’s.

This proves, in my opinion, that bootstrapping an Ubuntu port based on Android source code is not only possible, but is a viable way of supporting Android app developers who want to cross that chasm and target their apps for Ubuntu as well. I hope it will open the door for high-quality, native Ubuntu app ports from the Android ecosystem. There is still much more NDR can do to make this easier, and having people with more Android experience than me (that would be none) would certainly make it a more powerful tool, so I’m making it a public, open source project on Launchpad and am inviting anybody who has an interest in this to help me improve it.

I’ve been using Ubuntu on my only phone for over six months now, and I’ve been loving it. But all this time it’s been missing something, something I couldn’t quite put my finger on. Then, Saturday night, it finally hit me, it’s missing the community.

That’s not to say that the community isn’t involved in building it, all of the core apps have been community developed, as have several parts of our toolkit and even the platform itself. Everything about Ubuntu for phones is open source and open to the community.

But the community wasn’t on my phone. Their work was, but not the people. I have Facebook and Google+ and Twitter, sure, but everybody is on those, and you have to either follow or friend people there to see anything from them. I wanted something that put the community of Ubuntu phone users, on my Ubuntu phone. So, I started to make one.

Community Cast

Community Cast is a very simple, very basic, public message broadcasting service for Ubuntu. It’s not instant messaging, or social networking. It doesn’t to chat rooms or groups. It isn’t secure, at all. It does just one thing, it lets you send a short message to everybody else who uses it. It’s a place to say hello to other users of Ubuntu phone (or tablet). That’s it, that’s all.

As I mentioned at the start, I only realized what I wanted Saturday night, but after spending just a few hours on it, I’ve managed to get a barely functional client and server, which I’m making available now to anybody who wants to help build it.

Server

The server piece is a very small Django app, with a single BroadcastMessage data model, and the Django Rest Framework that allows you to list and post messages via JSON. To keep things simple, it doesn’t do any authentication yet, so it’s certainly not ready for any kind of production use. I would like it to get Ubuntu One authentication information from the client, but I’m still working out how to do that. I threw this very basic server up on our internal testing OpenStack cloud already, but it’s running the built-in http server and an sqlite3 database, so if it slows to a crawl or stops working don’t be surprised. Like I said, it’s not production ready. But if you want to help me get it there, you can get the code with bzr branch lp:~mhall119/+junk/communitycast-server, then just run syncdb and runserver to start it.

Client

The client is just as simple and unfinished as the server (I’ve only put a few hours into them both combined, remember?), but it’s enough to use. Again there’s no authentication, so anybody with the client code can post to my server, but I want to use the Ubuntu Online Accounts to authenticate a user via their Ubuntu One account. There’s also no automatic updating, you have to press the refresh button in the toolbar to check for new messages. But it works. You can get the code for it with bzr branch lp:~mhall119/+junk/communitycast-client and it will by default connect to my test instance. If you want to run your own server, you can change the baseUrl property on the MessageListModel to point to your local (or remote) server.

Screenshots

There isn’t much to show, but here’s what it looks like right now. I hope that there’s enough interest from others to get some better designs for the client and help implementing them and filling out the rest of the features on both the client and server.

Not bad for a few hours of work. I have a functional client and server, with the server even deployed to the cloud. Developing for Ubuntu is proving to be extremely fast and easy.

Yesterday we made a big step towards developing a native email client for Ubuntu, which uses the Ubuntu UI Toolkit and will converge between between phones, tablets and the desktop from the start.

We’re not starting from scratch though, we’re building on top of the incredible work done in the Trojitá project. Trojitá provides a fast, light email client built with Qt, which made it ideal for using with Ubuntu. And yesterday, the first of that work was accepted into upstream, you can now build an Ubuntu Components front end to Trojitá.

None of this would have been possible without the help up Trojitá’s upstream developer Jan Kundrát, who patiently helped me learn the codebase, and also the basics of CMake and Git so that I could make this first contribution. It also wouldn’t have been possible without the existing work by Ken VanDine and Joseph Mills, who both worked on the build configuration and some initial QML code that I used. Thanks also to Dan Chapman for working together with me to get this contribution into shape and accepted upstream.

This is just the start, now comes the hard work of actually building the new UI with the Ubuntu UI Toolkit. Andrea Del Sarto has provided some fantastic UI mockups already which we can use as a start, but there’s still a need for a more detailed visual and UX design. If you want to be part of that work, I’ve documented how to get the code and how to contribute on the EmailClient wiki. You can also join the next IRC meeting at 1400 UTC today in #ubuntu-touch-meeting on Freenode.

Today we announced the start of the next Ubuntu App Showdown, and I have very high hopes for the kinds of apps we’ll see this time around. Our SDK has grown by leaps and bounds since the last one, and so much more is possible now. So go get yourself started now: http://developer.ubuntu.com/apps/

Earlier today Jono posted his Top 5 Dream Ubuntu Apps, and they all sound great. I don’t have any specific apps I’d like to see, but I would love to get some multi-player games. Nothing fancy, nothing 3D or FPS. Think more like Draw Something or Words With Friends, something casual, turn-based, that lets me connect with other Ubuntu device users. A clone of one of those would be fun, but let’s try and come up with something original, something unique to Ubuntu.

For much of the past year I’ve been working on the Ubuntu API Website, a Django project for hosting all of the API documentation for the Ubuntu SDK, covering a variety of languages, toolkits and libraries. It’s been a lot of work for just one person, to make it really awesome I’m going to need help from you guys and gals in the community.

To help smooth the onramp to getting started, here is a breakdown of the different components in the site and how they all fit together. You should grab a copy of the branch from Launchpad so you can follow along by running: bzr branch lp:ubuntu-api-website

Django

First off, let’s talk about the framework. The API website uses Django, a very popular Python webapp framework that’s also used by other community-run Ubuntu websites, such as Summit and the LoCo Team Portal, which makes it a good fit. A Django project consists of one or more Django “apps”, which I will cover below. Each app consists of “models”, which use the Django ORM (Object-Relational Mapping) to handle all of the database interactions for us, so we can stick to just Python and not worry about SQL. Apps also have “views”, which are classes or functions that are called when a URL is requested. Finally, Django provides a default templating engine that views can use to produce HTML.

If you’re not familiar with Django already, you should take the online Tutorial. It only takes about an hour to go through it all, and by the end you’ll have learned all of the fundamental things about building a Django site.

Branch Root

When you first get the branch you’ll see one folder and a handful of files. The folder, developer_network, is the Django project root, inside there is all of the source code for the website. Most of your time is going to be spent in there.

Also in the branch root you’ll find some files that are used for managing the project itself. Most important of these is the README file, which gives step by step instructions for getting it running on your machine. You will want to follow these instructions before you start changing code. Among the instructions is using the requirements.txt file, also in the branch root, to setup a virtualenv environment. Virtualenv lets you create a Python runtime specifically for this project, without it conflicting with your system-wide Python installation.

The other files you can ignore for now, they’re used for packaging and deploying the site, you won’t need them during development.

./developer_network/

As I mentioned above, this folder is the Django project root. It has sub-folders for each of the Django apps used by this project. I will go into more detail on each of these apps below.

This folder also contains three important files for Django: manage.py, urls.py and settings.py

manage.py is used for a number of commands you can give to Django. In the README you’ll have seen it used to call syncdb, migrate and initdb. These create the database tables, apply any table schema changes, and load them with initial data. These commands only need to be run once. It also has you run collectstatic and runserver. The first collects static files (images, css, javascript, etc) from all of the apps and puts them all into a single ./static/ folder in the project root, you’ll need to run that whenever you change one of those files in an app. The second, runserver, runs a local HTTP server for your app, this is very handy during development when you don’t want to be bothered with a full Apache server. You can run this anytime you want to see your site “live”.

settings.py contains all of the Django configuration for the project. There’s too much to go into detail on here, and you’ll rarely need to touch it anyway.

urls.py is the file that maps URLs to an application’s views, it’s basically a list of regular-expressions that try to match the requested URL, and a python function or class to call for that match. If you took the Django project tutorial I recommended above, you should have a pretty good understanding of what it does. If you ever add a new view, you’ll need to add a corresponding line to this file in order for Django to know about it. If you want to know what view handles a given URL, you can just look it up here.

./developer_network/ubuntu_website/

If you followed the README in the branch root, the first thing it has you do is grab another bzr branch and put it in ./developer_network/ubuntu_website. This is a Django app that does nothing more than provide a base template for all of your project’s pages. It’s generic enough to be used by other Django-powered websites, so it’s kept in a separate branch that each one can pull from. It’s rare that you’ll need to make changes in here, but if you do just remember that you need to push you changes branch to the ubuntu-community-webthemes project on Launchpad.

./developer_network/rest_framework/

This is a 3rd party Django app that provides the RESTful JSON API for the site. You should not make changes to this app, since that would put us out of sync with the upstream code, and would make it difficult to pull in updates from them in the future. All of the code specific to the Ubuntu API Website’s services are in the developer_network/service/ app.

./developer_network/search/

This app isn’t being used yet, but it is intended for giving better search functionality to the site. There are some models here already, but nothing that is being used. So if searching is your thing, this is the app you’ll want to work in.

./developer_network/related/

This is another app that isn’t being used yet, but is intended to allow users to link additional content to the API documentation. This is one of the major goals of the site, and a relatively easy area to get started contributing. There are already models defined for code snippets, Images and links. Snippets and Links should be relatively straightforward to implement. Images will be a little harder, because the site runs on multiple instances in the cloud, and each instance will need access to the image, so we can’t just use the Django default of saving them to local files. This is the best place for you to make an impact on the site.

./developer_network/common/

The common app provides views for logging in and out of the app, as well as views for handling 404 and 500 errors when the arise. It also provides some base models the site’s page hierarchy. This starts with a Topic at the top, which would be qml or html5 in our site, followed by a Version which lets us host different sets of docs for the different supported releases of Ubuntu. Finally each set of docs is placed within a Section, such as Graphical Interface or Platform Service to help the user browse them based on use.

./developer_network/apidocs/

This app provides models that correspond directly to pieces of documentation that are being imported. Documentation can be imported either as an Element that represents a specific part of the API, such as a class or function, or as a Page that represents long-form text on how to use the Elements themselves. Each one of these may also have a given Namespace attached to it, if the imported language supports it, to further categorize them.

./developer_network/web/

Finally we get into the app that is actually generates the pages. This app has no models, but uses the ones defined in the common and apidocs apps. This app defines all of the views and templates used by the website’s pages, so no matter what you are working on there’s a good chance you’ll need to make changes in here too. The templates defined here use the ones in ubuntu_website as a base, and then add site and page specific markup for each.

Getting Started

If you’re still reading this far down, congratulations! You have all the information you need to dive in and start turning a boring but functional website into a dynamic, collaborative information hub for Ubuntu app developers. But you don’t need to go it alone, I’m on IRC all the time, so come find me (mhall119) in #ubuntu-website or #ubuntu-app-devel on Freenode and let me know where you want to start. If you don’t do IRC, leave a comment below and I’ll respond to it. And of course you can find the project, file bugs (or pick bugs to fix) and get the code all from the Launchpad project.

Last week I posted on G+ about the a couple of new sets of QML API docs that were published. Well that was only a part of the actual story of what’s been going on with the Ubuntu API website lately.

Over the last month I’ve been working on implementing and deploying a RESTful JSON service on top of the Ubuntu API website, and last week is when all of that work finally found it’s way into production. That means we now have a public, open API for accessing all of the information available on the API website itself! This opens up many interesting opportunities for integration and mashups, from integration with QtCreator in the Ubuntu SDK, to mobile reference apps to run on the Ubuntu phone, or anything else your imagination can come up with.

But what does this have to do with the new published docs? Well the RESTful service also gives us the ability to push documentation up to the production server, which is how those docs got there. I’ve been converting the old Django manage.py scripts that would import docs directly into the database, to instead push them to the website via the new service, and the QtMultimedia and QtFeedback API docs were the first ones to use it.

Best of all, the scripts are all automated, which means we can start integrating them with the continuous integration infrastructure that the rest of Ubuntu Engineering has been building around our projects. So in the near future, whenever there is a new daily build of the Ubuntu SDK, it will also push the new documentation up, so we will have both the stable release documentation as well as the daily development release documentation available online.

That’s it for today, the first day of my UbBloPoMo posts. The rest of this week I will be driving to and fro for a work sprint with the rest of my team, the Ubuntu SDK team, and many others involved in building the phone and app developer pieces for Ubuntu. So the rest of this week’s post may be much shorter. We’ll see.

So it’s not February first yet, but what the heck I’ll go ahead and get started early. I tried to do the whole NaBloPoMo thing a year or so ago, but didn’t make it more than a week. I hope to do better this time, and with that in mind I’ve decided to put together some kind of a plan.

First things first, I’m going to cheat and only plan on having a post published ever week day of the month, since it seems that’s when most people are reading my blog (and/or Planet Ubuntu) anyway, and it means I don’t have to worry about it over the weekends. If you really, really want to read a new post from me on Saturday……you should get a hobby. Then blog about it, on Planet Ubuntu.

To try and keep me from forgetting to blog during the days I am committing to, I’ve scheduled a recurring 30 minute slot on my calendar. UbBloPoMo posts should be something you can write up in 30 minutes or less, I think, so that should suffice. I’ve also scheduled it for the end of my work day, so I can talk about things that are still fresh in my mind, to make it even easier.

Finally, because Europe is off work by the end of my day, I’m going to schedule all of my posts to publish the following morning at 9am UTC (posts written Friday will publish on Monday morning). I’ve been doing this for a while with my previous posts, and it seems to get more views when I do. For example, this post was written yesterday, but posted while I was still sound asleep this morning. The internet is a magical place.

So, today being Friday, I will be writing my first actual UbBloPoMo entry this evening, and it will post on Monday February 3rd. What will it be about I wonder? The suspense is killing me.

First a disclaimer, these aren’t professional pictures. They were taken with my Nexus 4, also running Ubuntu Touch, and the colors are slightly shifted horizontally for some reason. I didn’t notice it until I had already gone through and taken 58 pictures and downloaded them to my laptop. Apologies for that. But you can still get a feel for it, so let’s carry on!

Edge Swiping

The touch screen and edge swiping worked perfectly, as was neatly demonstrated by going through the new introduction tour.

Dash & Launcher

The Dash also works exactly as expected. This build has a low enough pixel/grid-unit, and high enough resolution, that it fits 4 icons per row, the same as you get on Asus Nexus 4. The icons on the Launcher felt a little small, but everything there worked perfectly too.

Indicators

The indicators were missing some functionality, which I assume is a result of Ubuntu Touch not working with all of the Find 5′s hardware. Specifically the WiFi isn’t working, so you don’t see anything for it in the Network indicator, and the screen brightness slider was non-functional in the Battery indicator. Sound, however, worked perfectly.

Apps

Not having WiFi limited the number of apps I could play with, but most of the ones I could try worked fine. Sudoku and Dropping letters don’t work for some reason, but the Core Apps (except Weather, which requires network access) worked fine.

Hardware

As I already mentioned, WiFi doesn’t work on this build, nor does screen brightness. The camera, however, is a different story. Both the front and back cameras worked, including the flash on the back.

Final Thoughts

While this build didn’t meet all the criteria I had initially set out, it did so much more than any other image I had received up until now that I am happy to call it the winner. The developer who built it has also committed to continuing his porting work, and getting the remaining items working. I hope that having this Find 5 will help him in that work, and so all Find 5 owners will have the chance to run Ubuntu Touch on their device.

When we announced the Ubuntu Edge crowd-funding campaign a week ago, we had one hell of a good first day. We broke records left and right, we sold out of the first round of perks in half the time we expected, and we put the campaign well above the red line we needed to reach our goal. Our second day was also amazing, and when we opened up a new round of perks at a heavy discount the third day we got another big boost.

But as exciting and record-breaking as that first week was, we couldn’t escape the inevitable slowdown that the Kickstarter folks call “the trough“. Our funding didn’t stop, you guys never stopped, but it certainly slowed way down from it’s peak. We’ve now entered a period of the crowd-funding cycle where keeping momentum going is the most important thing. How well we do that will determine whether or not we’re close enough to our goal for the typical end-of-cycle peak to push us over the edge.

And this is where we need our community more than ever, not for your money but for your ideas and your passion. If you haven’t contributed to the campaign yet, what can we offer that would make it worthwhile for you? If your friends haven’t contributed yet, what would it take to make them interested? We want to know what perks to offer to help drive us through the trough and closer to the Edge.

Our Options

So here’s what we have to work with. We need to raise about $24 million by the end of August 21st. That’s a lot, but if we break it down by orders of magnitude we get the following combinations:

1,000,000 people giving $24 each

100,000 people giving $240 each

10,000 people giving $2,400 each

1,000 people giving $24,000 each

Now finding ways to get people to contribute $24 are easy, but a million people is a lot of people. 1,000 or even 10,000 people isn’t that many, but finding things that they’ll part with $2,400 for is challenge, even more so for $24,000.

That leaves us with one order of magnitude that I think makes sense. 100,000 people is a lot, but not unreasonable. Previously large crowd-funding campaigns have reached 90,000 contributors, while raising only a fraction of what we’re trying for, so that many people is an attainable goal. Plus $240, while more than an impulse purchase, still isn’t an unreasonable amount for a lot of people to part with, especially if we’re giving them something of similar real value in return.

Now it doesn’t have to be exactly $240, but think of perk ideas that would be around this level, something less than the cost of a phone, but more than the Founder levels.

Our Limits

Now, for the limitations we have. I know everybody wants to see $600 phones again, and that would certainly be an easy way to boost the campaign. But the manufacturing estimate we have is that $32 million will build only 40,000 phones. That’s $800 per phone. That’s something we can’t get away from. Whatever we offer as perks, we have to average at least $800 per phone. We were able to offer perks for less than that because we projected the other perk levels to help make up the difference. So if you’re going to suggest a lower-priced phone perk, you’re going to have to offer some way to make up the difference.

You also need to consider the cost of offering the perk, as a $50 t-shirt doesn’t actually net $50 once you take out the cost of the shirt itself, so we can’t offer $240 worth of merchandise in exchange for a $240 contribution. But you could probably offer something that costs $20 to make in exchange for a $240 contribution.

Our Challenge

So there’s the challenge for you guys. I’ve been thinking of this for over a week now, and have offered my ideas to those managing the campaign. Often they pointed out some flaw in my reasoning or estimates, but some ideas they liked and might try to offer. I can’t promise that your ideas will be offered, but I can promise to put them in front of the people making those decisions, and they are interested in hearing from you.

Now, rather than trying to cultivate your ideas here on my blog, because comments are a terrible place for something like that, I’ve created a Reddit thread for you. Post your ideas there as comments, upvote the ones you think are good, downvote the ones you don’t think are possible, leave comments and suggestions to help refine the ideas. I will let those running the campaign know about the thread, and I will also be taking the most popular (and possible) ideas and emailing them to the decision makers directly.

We have a long way to go to reach $32 million, but it’s still within our reach. With your ideas, and your help, we will make it to the Edge.

This is it, the final day of the Ubuntu Core Apps Hack Days! It’s been a long but very productive run, and it doesn’t mean the end of your chance to participate. You can always find us in #ubuntu-app-devel on Freenode IRC, and for today either myself (mhall119) or Alan Pope (popey) will be at your beck and call from 9am to 9pm to help you get setup and started working on the Core Apps.

The last of the Core Apps, and the one we will be focusing on today, is the Stock Ticker. Originally developed by independent developer Robert Steckroth, we recently invited the Stock Ticker into the Core Apps project where we have been focused on refining the UI and setting it up for automated testing. Feature wise, the Stock Ticker was already dogfoodable when we brought it under the Core Apps umbrella:

Search for stocks. DONE!

Add stocks to your portfolio. DONE!

Browse current stock prices. DONE!

Browse stock information. DONE!

For the UI we asked community designer Lucas Romero Di Benedetto to produce some new visual designs for us, which are looking incredible! But it’s going to take a lot of work to implement them all, so we really need some more developers, especially those who know their way around QML, to help us with this.

We only have 2 days left in the Ubuntu Core Apps Hack Days! I hope everybody who has participated has enjoyed it and found it informative and helpful. If you haven’t participated yet, it’s not too late! Come join us in #ubuntu-app-devel on Freenode’s IRC network anytime from 9am to 9pm UTC and ping either myself (mhall119) or Alan Pope (popey) and we’ll help you get setup and show you where you can start contributing to the Core Apps.

Today we get another chance to play while we work, because the focus is going to be on Dropping Letters, a simple, fun, yet surprisingly addictive little app written by Stuart Langridge. Stuart has since handed off development of the app to others, but not before having it already in perfectly usable state. Because of it’s simplicity, our list of dogfooding requirements wasn’t very long:

Start a new game. DONE!

View high scores.

Short as the list may be, it’s only half done! We still need to integrate a high scores screen, which means we need you Javascript and QML developers! Dropping Letters also needs to be tested, which means Autopilot, which of course means we have something for you Python hackers too! So come and join us today in #ubuntu-app-devel and help make this great game even better.

We’re back again for another Ubuntu Core Apps Hack Day! As always you can find us in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC, you can ping me (mhall119) or Alan Pope (popey) and we’ll help you get setup with a development environment and a copy of the Core Apps source code so you can start hacking.

Today’s app is one that was most requested when we announced Ubuntu on phones, and has since proven to be one of the most often used by developers and testers the like. That’s right, I’m talking about the Terminal! The Terminal went through very rapid development, thanks to the herculean efforts of one very talented developer, and the ability to re-use the KTerminal QML component from KDE’s Konsole project. Because of both, the Terminal app has been dogfoodable for a while now.

Issue commands. DONE!

Use case: ssh into another computer. DONE!

Use case: edit a file with vi. DONE!

Use case: tail a log file. DONE!

Use case: apt-get update. DONE!

But that doesn’t mean that the work here is done. For starters, we need to make sure that changes to the KTerminal code are submitted back upsteam, something we could certainly use some help from somebody who is familiar with either Konsole’s development specifically or KDE in general. We also want to improve the availability of special keys like the function keys and ctrl+ combinations that are oh so useful when interacting with the command line, so anybody with QML/Javascript experience or who is familiar with the on-screen keyboard specifically would be able to help us out quite a bit here.

Last week was certainly an exciting one, between the Ubuntu Edge campaign announcement and several coworkers being at OSCON, I wasn’t able to keep the Hack Days going. So we’ve decided to pick up where we left off this week, covering the remaining Core Apps on our list. Just like before we’ll be hanging out in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC, and will be more than happy to walk you through the process of getting started.

Today we’re going to work on the Document Viewer, a necessary app for most people, which is at the same time both simple and very complicated. The app itself doesn’t require a lot of functionality, but it does need a lot of behind-the-scenes components to load and render documents of different formats. Great progress has already been made on our dogfooding requirements list:

Load a text file. DONE!

Load an image file. DONE!

Load a PDF.

View the file. DONE!

Forward/back pages on PDF.

Pinch to zoom.

Until just yesterday, there wasn’t a released version of our desktop PDF library (Poppler) that had Qt5 bindings. However, with the release of Poppler 0.24 yesterday, we should not be ready to start implementing the PDF support. We also need to replace the existing C++ wrapper used to launch the app with the new Arguments QML component, but when we do that we’ll need another QML plugin that will give us the mime-type of the files that are being loaded. And of course we need to make sure we have full Autopilot test coverage for all of these parts. So whether your skill set is Python, QML, Javascript or C++, there is something you can contribute to on this app.

There’s been a lot of talk about the Ubuntu Edge, and our associated Indiegogo campaign to fund it. There has been a lot of positive coverage on news sites, social media, Reddit and even one television interview. But there have also been a lot of questions about why we’re doing this, and why we’ve chosen a crowd-funding campaign to do it. Since I’ve seen so many of the same questions being asked by so many people, I wanted to take the time to try and explain things a little bit better.

What it isn’t

In order to fully understand and appreciate what the campaign is about, it might be easiest to first explain fully what it isn’t. Once we’ve done away with these misconceptions, it should become more clear why it is what it is, and finally why that is important.

First of all, and perhaps most importantly, this is not a charity. We have provided a $20 perk for people who want to see this campaign succeed but don’t have the means or desire to purchase one of the Ubuntu Edge devices. But this is primarily a way for people to get very high-end hardware by paying for it’s creation. I don’t have the exact numbers, but just going by what we’ve seen of the perks claimed, people have been contributing at levels that would get them a phone more than 3.5 times more often than the much less expensive founder’s perk. This tells me that people aren’t supporting this campaign because they think it’s a good cause, or because they like what Canonical is doing, by and large they are supporting this campaign because they want an Ubuntu Edge in return.

Secondly, and this is one that has been asked a lot, this is not a financial investment. OEMs aren’t stupid, venture capitalists aren’t stupid, and Mark Shuttleworth isn’t stupid. If there was money to be made in building bleeding-edge phones then we would have half a dozen to choose from at our local store. The margins on hardware sales is much lower than many people realize, and without a high rate of profits available, only a very low level of risk can be assumed. That’s the main reason nobody else has built a phone like the Ubuntu Edge, and why nobody is going to anytime soon if we were to try and do it using capital investments. The Ubuntu Edge doesn’t need to prove that people want scratch-proof screens or high-capacity batteries, it doesn’t need to prove that consumers like more power and more storage, it needs to prove that those technologies are ready to be produced in high volumes without supply or manufacturing problems. It doesn’t need to prove that people want a desktop available at home or work, but it does need to prove that the hardware and software are capable now of providing that convergence in a satisfactory way that previous attempts couldn’t.

Finally, it’s not a way of making money for Canonical or a last-ditch effort for keeping either Ubuntu or Ubuntu Touch alive. Whether this campaign succeeds or fails, we will continue to work with OEMs to bring multiple consumer phones to market, most likely using slightly better hardware than the current generation of smart phones, where there is little risk involved on the hardware side. But in order for Ubuntu to provide the kind of convergence and one-device experience that we envision, we needed skip the slow, safe evolution of hardware and spark the flames on a whole new class of phone. So while we work on getting Ubuntu phones to market with our partners, the Ubuntu Edge will provide the seeds for the suppliers and manufacturers that those partners use, so they will be ready to build their new generation of superphones when the time comes.

What it is

Now that I’ve gone over what this campaign isn’t, let talk about what it is. I spent some time over this weekend thinking about how to accurately describe it without going deep into the economics or politics of it, trying to find parallels in other industries (like Mark’s F-1 analogy) that wouldn’t fall apart when going into the specifics of either. In the end, I decided that the thing this campaign resembles the most is an adventure.

Now that’s vague, I know, so let me give some more concrete examples. I liked Mark’s F-1 analogy, but when looking into how F-1 actually operates these days it really doesn’t quite fit. Instead it’s more like X-Prize competition that put the first private manned vehicle into space. Even though there was a monetary prize in that competition, it was only a tiny fraction of the money that went into building any of the entrants. The reason anybody participated was to push the bounds of technology and to try and birth a new industry, one where they would stand to benefit more in the long run than any possible profits they could have made by sticking with the status quo.

But those initiatives were largely funded by wealthy individuals, who probably didn’t expect to get much in return. So for a more fitting analogy we need to go a bit further back in time, to expeditions into the Americas and Africa, some of which were funded only by those who were to participate in them, and who could expect little more than the thrill of participating. While not pushing the limits of technology, these adventurers would certainly push the bounds of knowledge to new levels, and would fundamentally change the way the world looked.

[Update] It has been pointed out in the comments that many of these expeditions had either deplorable intents or disasterous consequences for the native people. While this was not at all what I had in mind, I understand that my knowledge of those histories is largely influenced by my own ancestry. A better example, as also pointed out in the comments, would be the expeditions to both the north and south poles, or the scaling of Everest.

Why it’s important

Now both of these are extreme examples, and certainly far outshine what we’re trying to do with the Ubuntu Edge. It is just a computer after all. But on a smaller scale the reasons and motivations are the same, there is a desire to push the limits that currently confine us. And that’s certainly not a feeling that’s limited to Canonical, over 15,000 people have contributed to the campaign in one way or another, and around 10,000 have committed to sharing the adventure with us from the beginning by claiming their own phone. These aren’t wealthy investors looking to become more wealthy, nor is it good-hearted folks who are giving us money just to be nice, these are thousands of people who want go on the adventure because it’s exciting, because it’s audacious, and because it gives them the future they want to see made.

So there it is, we’re embarking on an adventure, and we want you to come with us. If the Ubuntu Edge makes you excited for the future of computing, if you’re eager to see that future technology years before it becomes common place, if you want be on of the ones cutting new trails rather than following those well-worn paths cut years ago, then I invite you to sign up and add your name to the list of technology pioneers.

So you may have heard (seriously, how could you not?) that Canonical is crowd-funding a showcase phone called Ubuntu Edge. This is very exciting for a number of reasons, which I will get to below, but first go look at the Indie GoGo campaign page to see what I’m talking about.

Back? Good. Did you contribute? For the first 24 hours you can get a phone for a highly discounted contribution of $600 USD, rather than the $830 USD it will cost you tomorrow, so if you really want one of these it’s best to put your money on the table now.

Hardware Innovation

The phone hardware is impressive on it’s own, with more CPU, RAM and storage space than the laptop I was using for daily work last year. Not only that, but it’s going to feature advances in the glass and battery that I haven’t seen on other phones. Sapphire crystal glass, which can only be scratched by diamond, will keep your screen looking brand new for years to come. And the silicon-anode battery promises faster charging and longer runtime without increasing the size of the handset. You can see the full spec list on our other announcements.

I like this because we’re not asking you to contribute to making just another ordinary phone like all the rest you can buy already. Instead we’re pushing the envelope to pioneer a new class of convergent superphones, a market that Ubuntu is uniquely positioned for. This hardware will run Ubuntu Touch, Ubuntu for Android, and (when docked) a full Ubuntu Desktop. But we’re not just playing the “make it bigger, make it faster” game, the design of Ubuntu Edge’s hardware is deliberate, everything choice was made based on what would provide the best user experience, what would make the edge-swipe gestures easy and responsive, what would let us show more of an app’s content while still fitting into the palm of the user’s hand. This is a device designed from top to bottom for Ubuntu.

The margin on most production phones is thin enough to see though, which means that an OEM can’t afford to take risks with emerging technology or markets. That’s why it’s so important that we prove both the capabilities of Ubuntu for convergence, and the consumer appeal for such a device. Apple had to do it with the original iPhone, Google does it with their Nexus line of devices, and now it’s our turn to show what’s possible.

Community Campaign

Instead of seeking private capital to build these phones, then trying to sell them (at a profit or loss), we’ve decided to take it directly to the user community, which is why we’re asking you to pledge some amount to our campaign. We couldn’t build Ubuntu without our community, and we can’t build Ubuntu Edge without you either.

Our target goal is $32 million, which sounds like a lot, but only because it is. It really is. But it’s still only a fraction of the cost of an actual production line of phones. In order for an OEM to ship an Ubuntu phone (or any new phone), they would typically invest multiple times this amount. So as big as our target goal is, and I don’t think anybody’s crowd-sourced more, it’s certainly not an unreasonable amount for what we’re offering.

The target amount will allow us to manufacture just 40,000 handsets, most of which I would imagine will already be claimed by those contributing $830 or more (only $600 if you do it the first day!). All of the money raised in this campaign will go directly towards manufacturing and shipping these devices, it won’t be used for other Canonical business or even future Ubuntu development. When you do the math, which I did, you see that it comes out to $800 per device to manufacture, and we’re only asking for $830 to get it (again, in the first 24 hours, you can get it below that cost). This is an effort to build a new class of superphone, not a way of making Canonical rich. If we reach our goal, you should have your Ubuntu Edge in hand sometime in May 2014!

Non-monetary contributions

I know that $830 is a lot of money, even $600 is a lot of money, but those aren’t the only ways you can help. In addition to giving smaller amounts in support of this campaign (for which there are other perks) you can help make it a success by spreading the word. No doubt it will be picked up by the usual online news sources, forums and blogs but let’s break it out of our usual Linux/FLOSS sphere.

So share links to the Indie GoGo campaign page on Facebook, Twitter and Google+. Tell your friends, especially any tech savvy ones, about it. Send an email to your local newspaper, radio or television stations, you never know who might think it’s an interesting story (and wouldn’t you just love to see Ubuntu on TV?). Every person you tell about the campaign brings us one step closer to reaching our goal, and it doesn’t cost you a penny.

We’ve had a great week running the Ubuntu Core Apps Hack Days so far, we’ve seen several new contributors join our development teams, and lots of merge proposals coming in and landing. But we’re not done yet, we’ll be in #ubuntu-app-devel again today from 9am to 9pm UTC to help anybody who is interested in getting started contributing to these apps.

Today we’ll be focusing on an app that may not be high on the average user’s list of mobile apps, but is indispensable for anybody working on a ported image or writing an app for Ubuntu Touch, that is the File Manager App!

Thanks to reusing the Folder List Model QML Plugin from the Nemo Mobile project, the File Manager developers were able to get a very functional application working in a very short amount of time. That means that our dogfooding list is already complete!

Browse folders. DONE!

View files within folders. DONE!

View file information. DONE!

Copy files. DONE!

Delete files. DONE!

Move files. DONE!

But don’t let that list fool you, there’s still plenty of work to be done. The biggest one is making sure that any changes we’ve made to the Nemo plugin are sent back upstream. If anybody from the Nemo project can help us with this, please find me (mhall119 on IRC). We also need to make sure we have full Autopilot test coverage, and fix any remaining bugs that have been reported.

I hope you all enjoyed spending some time playing Sudoku yesterday, because we’re back to work again for another Ubuntu Core App Hack Day! As always you can find us in #ubuntu-app-devel on Freenode IRC from 9am to 9pm UTC to answer all of your app hacking questions, help get you setup and started contributing, or just generally discuss how to write Ubuntu Touch apps in general.

Today we leave behind yesterday’s light hearted fun and games and turn to the (only slightly) more serious work of reading news with the RSS Reader app! Another one of the original Core Apps, the RSS Reader got some unexpected designs from the Canonical Design team that converted it from the typical list-of-headlines to a beautiful organic grid seen here.

Because of these very recent and very major changes to the UI, there’s a lot of work to be done to get all of the previous functionality working again at the same level. For dogfooding the RSS Reader, these are our goals:

Add a feed.

Browse feeds. DONE!

View a feed.

Select an item to view from within the feed.

Because of the major changes, this app can use a lot of help from people who are simply willing to use it and report bugs so that the developers (and all of you new contributors) have a list of things to work on. Then we need you QML/Javascript hackers to pick things from that list and start making and submitting your fixes. Finally we need Autopilot tests written or updated for this new look, so I’m looking at you Python guys and gals to lend us a hand too.

We’re continuing our Ubuntu Core Apps Hack Days again today in the #ubuntu-app-devel channel on Freenode IRC, from 9am to 9pm UTC. If you want to learn more about the Core Apps and how you can get involved, jump into the channel and give myself (mhall119), Alan Pope (popey) or David Planella (dpm) a shout.

We’ve been working hard on the Core Apps lately, which is why I’m glad that today we get spend time on something a little more fun: the Sudoku App! Sudoku was originally developed outside of the Core Apps umbrella, but it progressed so quickly and fit Ubuntu Touch so well, that we invited it’s developer to join the rest of our Core Apps.

Sudoku was so far along before joining the Core Apps, that our dogfooding list was already largely complete:

Start a new game DONE!

Record and display game statistics DONE!

Provide hints DONE!

But even as complete as it is, there are still a few bugs to squash and some final Autopilot tests to write, so if you have QML and Javascript skills or Python skills and can spare a little bit of your time, you can help us put the finishing touches on this classic game. And if you want to help us, you know, “test” it for a few hours of your day, we’ll totally consider that a contribution too.