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?
Personally, I think Quickly was – and still is – a very good idea. I don’t know if it is realistic to expect Ubuntu to come up with a all-in-one integrated IDE that covers everything. Nor do I think this would be desirable.
What is good about Quickly? It borrows its main ideas from tools like django-admin/manage.py, which web developers are already comfortable with. It doesn’t try to hide things from you, you still use a terminal and all, but it makes things easy where they should be easy. No packaging, no release tarball packing, no writing changelogs – it is all be done for you.
Why is Quickly not enough? First, it seems to me that quickly is at the same time promoted as a core developer tool, and a spare-time project of a few dedicated Canonical employees. This is not the horse-power that is required to make an excellent developer toolkit. The Quickly Reboot initiative is great, now the projects needs some support from within and outside Canonical.
Plus, it’s all about the templates. The ones that Quickly currently provides are not bad. But they changed quite a lot during development, and it seems like it still is not clear what an Ubuntu App is supposed to look like. This is the step that should accompany building a strong Quickly core: Design an excellent example UI and provide templates for C/Vala/Python.
I am sure there are other opinions, and rightly so. But for my part, this would be all I’d need.
I think you’re right. The scale of investment and intensity of energy in this area appears too low. We need at least an order of magnitude increase ASAP. The question is, how?
I think that Ubuntu is taking the right first steps with Qt/QML and having Qt Creator as the standard IDE. Quickly was a nice little project but as a casual developer, it was not what I wanted. I also do not want Ubuntu to have a 1000 different frameworks and components when it isn’t necessary. Personally I think the desktop Unity should be built with the same technologies that the other version use and Qt is a good technology because it is a technology that many professionals are familiar with (compare to Gtk which is used more by hobbiest). What I think Ubuntu should focus more is on back-end technology like what Elementary OS has so that developers know how to share with other applications or core functionality with ease.
I think at it’s root the problem isn’t the choices your making but the way your going about making choices. Who are these tools for?
If I create a faux archetype (hopefully with a grain of plausability) who use your products and question your choices against them it makes the conversation shorter.
Jimmy Nguyen
Jimmy is a student who learned that he has a natural talent for programming he was originally passing time (in a way that will please his parents) while the contract for his first job expired and is studying a diploma in I.T and has decided to major in programming. Jimmy heard from one of his teachers about linux and an OS called Ubuntu and has decided to use it. To Jimmy Ubuntu sounds cool and he is learning about Ubuntu and he had only heard of WIN/Mac os before. So far he has learned to write some basic VB, Java, HTML and PHP. Jimmy is trying to create a sound recording app and he is caught up hearing about GStreamer, PulseAudio, Phonon and ALSA. Jimmy can’t even save a file he tried to create a folder /recordings but couldn’t get that working.
With Jimmy in mind the conclusions I would have come up with are
*C or C++ is plain wrong for him, the pitfalls of memory management are obvious
*Vala would be scary as it spits out warnings and has a lot of random errors when converting to c
*Python is going to run into weird type errors with terms that are used in glib, gstreamer, gtk and so on. Jimmy will run into the pitfalls of a new programmer not knowing the intricacies of these libraries.
*Jimmy will run into errors as the GIO bindings are updated when he moves to the next release.
*how does he learn that Gstreamer is the appropriate choice
*Jimmy has to battle with learning a new file system, the terminal and an application that is not discoverable outside of documentation
*How does Jimmy make a choice of IDE to use when also choosing a foreign language
*quickly and Gedit would appear half baked compared to other ide’s that exist
*what is revision control
For all Quicklys opinionated decisions it hasn’t done anything to help Jimmy. The ubuntu developer website doesn’t help him as it’s more a convergence of information rather than providing what he needs. The Gstreamer docs he needs are theory based and Jimmy is going to get confused when he tries to read the api docs first to save time. Jimmy is all but ignored.
What happens with an IPhone app developer. A windows developer. That smart kid who was never taught to program. A web developer. A mother who writes apps in her spare time (what little there is) between sole parenting three children. A person wanting to integrate there website with Ubuntu.
Are you making opinionated decisions for these people or making an opinionated decision simply because it affords you a way of wading through the endless minutiae programmers become obsessed with?
@Stevie G: Exactly what I think.
Nowadays it seems like Git is the VCS and a lot developer are using it, why not use git instead of bzr?
As a new developer I wanna hear:
– this is the IDE to use
– these are the frameworks to use
– here is the documentation… -> android example: http://goo.gl/OAMHI
– take a look at these example applications…
– some best practice tips and coding conventions
What you see as Quickly’s weakness looks to me like a strength. FOSS programmers tend to have very strong opinions of their own about things like editors, so a kit that makes strong, opinionated decisions will be rejected by everyone with differing opinions.
Quickly gives us some important project management features, but lets people use tools they’re comfortable with. I think that flexibility is valuable, although I agree that it might be good to have a recommended set of tools for new developers.
@Paradiesstaub – Git and Bzr are so close functionally for non-complex projects that a good design would be to simply communicate with a given service of choice. On GitHub? it’ll use git, Using launchpad? bzr it is. The developer really should have to learn two stupid interfaces for committing files to a VCS. Although i might just want to hold onto bzr because it’s not designed quite as badly as git’s cli tools.
@Thomas – The problem isn’t freedom, I’d have said that having any axis of freedom available for developers would be quite eloquent. The problem is one of focus. Quickly isn’t focused enough on a standard set of tools and falls to quickly into an Everyman role. Something that damages it’s mission brief and it’s ability to invest wisely into the next level of refinement. But that might be more a problem with the project’s mission rather than it’s tech.
im sure im probably just an ant yelling at the mountain.. but…
if you want to see what is wrong with the ubuntu phone idea… i think you guys better take a few hundred steps back first…..
the primary problem is ubuntu and the community itself.
as much as the ubuntu / linux community loves to brag about its capabilities and “back end” what is often distributed is a ferrari that needs the motor turned by handcrank to start it…and plastic lawn furniture to pass as seating…
the main reason why ?????????
its your own fault….
yup…. i don’t mean to be rude…i mean to be real.
if you’d like a test follow my logic…
computers for me started in the mid 80’s (atom)
then after a few hiccups and years i ended up with a dx66 in between we added a mouse and dos 6.1 and windows 3.1 / win 95 etc… this was the beginning of the end for the keyboard.
we have now moved on to the touchscreen and VERY soon to move onto voice command.
im sorry but the love of the keyboard and the command line has got to die.
the new smart/super phones NEVER need the command line for what can only be considered the basics of computer functionality.
all the bluetooth, usb, wifi, networkig and the like need a BARE minimum IF ANY text input to get the desired result
I WISH i could wander into a development room and find a CEO and 50 developers having a chat… where i could sneak around and steal all the keyboards.
………….that probably still wouldn’t make the point………….
the world has moved on…from entering text to do almost anything other than quasi social interaction….
its make or break time…GOOGLE stole your base system and turned it into the future by doing what you refused…they got rid of the need for a command line…with a check box and touchscreen.
now is the time to realise that a 20″ $200 monitor and the $100 andoid hdmi sticks are racing past you guys and your hardware keyboards….
i know you must LOVE LOVE LOVE your keyboards as the GUI was rubbed in your faces 15++ years ago and you didnt listen.
so heres your chance…. make ubuntu do EVERYTHING that windows does now…but without a keyboard.
heres a short list of items DESPERATELY NEEDED.
a GUI FOR EVERYTHING
a GUI FOR EVERYTHING
a “control panel”
a hardware manager that actually manages and lists all devices attached currently and past and their status…in 1 click/touch
A “double tap” / right click option for uninstall.
Programs that actually stop..(dead AND gone)
Full seamless incremental control over sychronisation of personal data files links web history photos videos shares emails texts.
fulltime documentating interaction with the UI ( all calls logged to calendar with notes and recordings linked together through the calendar and the web. full control of all permissions and start triggers for any applications (user denial of permissions / start triggers etc)
ALL without a single character of text inputted by the end user.
if you can achieve this you can call yourself ready for 2008!!
FULL ubuntu CANNOT do this yet…
the linux community has been nothing but insulting towards this proposal.
Rim hated me when I told them touchscreen was the future too.
this is the requirements of the next 8-16 months if youd like to be up to speed i suggest you get 12.04 ubuntu caught up as well
@jimmi – The command line is something that is not as useful for typical users, but I wouldn’t get rid of it. It’s far too powerful. your inability to use it does not mean it’s not more powerful than a GUI. Now it may be that cli tools could be over-run by visual functionality, and it might be that cli tools are clouding our ability to make visual tools. But in either way your response is far too harsh and lacking in working out.
I actually see Ubuntu deployed into normal homes, with normal users. I know very well where the holes are and were the features are. and we’re actually meeting a lot of functionality already, far more than one would suppose reading your post here.
Over all, we need more resources, which means more people, which means more belief. come back and point out pile of crap behind the curtain once we’re successfully over-resourced like RedHat.