Developer Kits

With the new Ubuntu Phone on the horizon I though I might pen something about developer kits. I think we’ve come to the group-conclusion that development on Ubuntu sucks, and it sucks in a few ways I’m going to ramble on through:

Coherence

The idea of Quickly was to make a few opinionated decisions about how programs should be made. But it seemed to very quickly delve into the empire of choices on libraries, languages project management and deployment strategies. And that’s a reflection on how hard it is to please everyone in the open source universe.

If we want to have a good developer kit, we need to have strong, very strong opinionated decisions which nail all the technical functionality that will be required for all sorts of apps. For the Ubuntu phone, this looks like Qt and OpenGL. For the desktop it looks like C/Vala/python and Gtk.

What we don’t have is a good story for the project management and deployment. It looks like deployment is going to be patched up with automated package testing and an automated security system. I’m not sure about project management on the developer’s work station yet, it’s still very ad-hoc with too much of the best workflow in the minds of the developers and not in the tools being used.

Investment

The developer desktop, tools, apis and workflows require an enormous amount of investment. Look at how much money and time Google has spent just on Android developer tools.

It’s practically another Ubuntu sized project. While traditionally we’ve had very little investment and have used whatever tools people have cobbled together as they went along with their own developer needs. It’s produced a very disjointed experience for new developers, where so much needed to be known in order to be a good developer.

That’s turning round with the new developer site and api documentation. but I’m not sure the size of investment is the right sort of scale for where we want to go with app development. Bringing together all the API documentation from our various libraries would go a long way towards centralising and authenticating the previous opinionated decisions.

The Klein Toolbox

It’s hard to know where a toolbox starts for app developers and ends for desktop/core developers. If you think about tools like bzr and Make; these tools are designed for core developers and not really intended for app developers. They require the developer to understand where to get the best workflows and be pre-trained. And this really means that as soon as a developer is capable of using these tools, they’re no longer capable of making good developer tools for app developers… how can someone be sympathetic to the needs of more casual developers when they were required to learn so very much?

I’ve never liked Makefiles, I don’t think they’re good enough and I’m damn petty about all the tools that generate makefiles too. I don’t see good design in that space and I know paultag disagrees with me quite strongly about how unawesome makefiles are.

Conclusion

We have a lot of work to do.

What do you conclude?

What are you Ubuntu, a Platform or a Product?

For today’s video blog I’m tackling the ideas behind Ubuntu the platform and Ubuntu the product, courtesy of Ayatana Mailing List. Nobody doesn’t like good Ayatana! Basically I dig into the problems between a One and Only vision and the more flexible, but harder to do, platform model of design.

With visual aids thanks to Inkscape!

Video Problems: Go directly to the video on blip.tv here and download the source ogv here.

What are your thoughts?