No, we are not infringing any licenses

We spend a lot of time making sure we’re not violating any licenses, and usually work with upstream early on. Charlie Smotherman got confused about how we had implemented music streaming and filed a bug reporting a violation. I’d encourage anyone who even suspects there may be a license violation to report a bug or contact us as soon as possible, but maybe hold off on the inflammatory blog posts  😉
We’ve contacted him explaining all this but he seems to not had a chance to update his claims so I’m bringing this up now.

Nobody on the Ubuntu One team commented on any of his blog posts either. Ampache seems like a nice piece of software and even some people on the Ubuntu One team use it. We chose to go with Subsonic clients (we are not using any of the server pieces as it doesn’t fit with our infrastructure) because the API seemed to be very nice, the existing clients where very nice to use, and all upstream developers where friendly and happy to help us release the service.

I’m sorry if any feelings got hurt, but there’s no need to lash out like that.

For future reference, the whole team hangs out in #ubuntuone on Freenode.

Why (I think) Ubuntu One exists

One of the questions that took a little while for me to fully understand was a very simple one: why does Ubuntu One exist?

Depending on who you ask, you may get a different answer, but here’s my take on it.

Above all, to extend the power of Ubuntu as an environment. Ubuntu One already allows you to many things beyond the basic file sync we started off with, you can keep your contacts from your phone and desktop  (and between other Ubuntu devices) in sync and backed up, notes, bookmarks, all your important files are backed up and synced, you can share them privately or publicly, you can buy music that gets delivered right to your music player, and soon you will be able to stream any of your music to your phone. And this is just today. As the project matures, we are working hard to make it easy for more and more third-party projects to use our platform and out-pace us in ideas and code.
All of this allows Ubuntu to extend its reach into mobile devices and even other operating systems. It feels like integrating into the real world today, not only the world we want to build.

Openness is the next thing on my mind. I know about all the criticisms about the server software not being open, I understand them and I’ve been through this same process with Launchpad. Right now, Canonical doesn’t see a way to fund a 30+ developer team of rockstars, a huge infrastructure and bandwidth usage that is mostly used at no cost and still offer up the code to any competitor who could set up a competing project within minutes. I am sure someday, just like with Launchpad, we will figure it out and I will see all my commits push me up thousands of positions on ohloh. Until then, I’ll have to continue working on Wikkid or any of the other 20 projects I use and am interested in, to keep me at a decent ranking.
All that said, the Ubuntu One team releases tons of source code all the time. A lot of the libraries we build are open sourced as soon as we get some time to clean them up and split it out of our source tree. All our desktop clients are open source from the start. On top of that, we work on pieces like desktopcouch, enabling couchdb for the desktop. We even got the chance to work with a closed-source iphone application, iSub, to open source his code so we could base our new streaming client on. We get to pay developers of open source projects on the Android platform as well, to work on improving it so we can deliver a better and more secure experience. We also get a chance to learn to package applications and upload new versions of the libraries we use to the Ubuntu repositories. And hundreds of other small things we do that feel so natural we forget to advertise and be proud of. All of this on Canonical’s dime.

Finally, a goal that is dear to my heart. Make Canonical profitable. I have been overwhelmed over and over again by the passion with which Mark personally, and the company as a whole, contributes to making open source be the standard way of developing software in the world. I can understand why it’s easy to feel uncomfortable with a privately owned company pursuing a profit while sponsoring an open source project which thousands of people contribute to, but after having sat down in dozens of meetings where everybody there cared about making sure we continue to grow as a community and that open source continues to win over tens of thousands of computers each month, I only worry about Canonical *not* being sustainable and constantly growing.

All these reasons for working on Ubuntu One have been close to my heart for many years now, a long time before I took the final step of investing not only my free time, but my work time, leisure time, and not too seldom, my sleep time,  and started working for Canonical in a very strict sense of the term “full time”.

I’ve spent time working in a few different teams, all of them are interesting, exceptionally skilled and open source is a core part of their lives. Ubuntu One is where I feel I can do the most impact today, and I’m beyond lucky to have given the opportunity to act on it.

Making usability part of the development process

For the first year and a half in Canonical I worked with the amazing Launchpad team, with the ambitious goal of building a new user interface, introducing AJAX in an established code base and rolling it all out on time. While all of that was overwhelming in itself, what was more important to me was making sure the UI remained consistent across time.
Long story short, it was a success and it’s been 8 months since I’ve left the team and the established process is still on-going.

I wrote a paper on the whole experience and presented it at the agile conference XP2010 in Norway.

Here’s the introduction:

When I started working with the Launchpad team I was tasked with designing and rolling out a new interface using cutting-edge technology on a well established product and team. The existing processes and team structure made it very hard to roll out big changes while also ensuring consistency as time went by.
While the general designs and work ow changes were being eshed out, I started to drive some change to the existing processes, enabling me to be successful at an objective that would take a year to accomplish, and unexpectedly, beyond that.
The project was 4 years old and had over 500 dynamic pages with different templates and layouts that had been left untouched at different points in time. The goal for the next year was to make the application easier to use, even enjoyable. I also had to make the UI consistent across the board, take the project from static HTML pages into the wonderful world of in-line editing, streamlined work-flows and predictable interactions. In parallel, fundamental features that had been developed were going completely unused and we needed to turn that around. A re-usable AJAX infrastructure had to be developed from the ground up, new features needed to be designed and delivered, and general navigation issues needed to be addressed.
However, this story isn’t about the success of the roll out of a new interface, but rather the success in the process changes that evolved during that year and how the project went from nobody feeling ownership over the user interface, to the developers taking strong ownership.

I feel very passionate about this subject, and hope this experience can help other projects and teams.

Here’s the paper for download: xp2010_paper.pdf