I met Ryan Paul at UDS last may and I must say I was star struck (I am star struck most of the time at UDS anyhow). As a badass editor at arstechnica and the man who started gwibber I thought it would be nice to interview for OMG! Ubuntu!
So hey dude, introduce yourself to our readers please and tell us about your story with Open Source?
I’m the Linux and open source editor at Ars Technica and the lead developer of the Gwibber project.
I had my earliest experience with open source software when I developed a MUD (multiuser text-based roleplaying game, based loosely on Dungeons and Dragons) in high school. I used the open source SMAUG code base and published several of my patches. SMAUG is the name of a popular MUD code base, derived from Merc.
So by day you’re a journalist and by night you are a hacker? How do you find time for both?
Yes, it’s difficult to find time. I have to rely on other contributors to do a lot of the basic upkeep like bug triaging. Members of the Ubuntu community have been very helpful with those kinds of tasks, which means that I can devote what little hacking time I have to making major changes and improvements to the code.
Can you tell me how your Gwibber story started? What was your inspiration?
It started like every other small tool that I develop for my own personal use. As it evolved, I started using it as a testbed for experimenting with new frameworks and development tools that I wanted to write about in articles. When Jorge Castro talked me into trying out Launchpad, I decided to migrate the Gwibber code to the site. That was the point at which Gwibber really took off and became popular.
The number of users grew considerably and I started getting patches from contributors. I realized that managing a real-world open source project could be a useful way to gain insight into the development process, so I decided to continue moving forward with the project.
I think that a lot of Gwibber’s early success is attributable to Jorge. He got people excited about the project and helped me get past my initial anxiety about being the maintainer of a serious public open source project.
Talking of Ubuntu it must be pretty awesome to see the app at the “crux” of Ubuntu’s ‘Social from the start’ initiative. How has this impacted on the direction of Gwibber?
Ubuntu’s Social from the Start initiative has driven a lot of the decisions that have been made over the past year about Gwibber’s architecture. In particular, our decision to separate the underlying service from the frontend was driven entirely by Ubuntu’s requirements.
There’s no doubt that Gwibber set the pace and the standard for social clients on the Linux desktop but, of late, the app has a bit of a reputation as a slow, resource-chomping beast that many users – despite the Ubuntu integration – don’t use. Do you think that image is fair? Is making a leaner Gwibber something that is a priority?
The perception that Gwibber is slow and excessively resource-intensive is absolutely fair, but it’s something that I’ve been working to improve. I don’t think that it has cost us many users, however. The statistics that we get from some of the social networking services show that our audience has grown steadily. Although some of the alternatives to Gwibber are much lighter, none offer equivalent functionality yet. My goal with Gwibber has always been to test new technologies and new components of the desktop stack, but sometimes I adopt new technologies prematurely.
Gwibber’s reliance on DesktopCouch has had a deeply negative impact on performance, reliability, and portability across distros. We have switched to SQLite in Gwibber 3, which significantly improves the program’s performance and responsiveness. In the future, we are going to be more cautious about adopting unproven technologies.
I think that our new version will help improve Gwibber’s reputation, but there is still more work to do. I think that the WebKit renderer is still too memory-intensive and the use of Python for the frontend makes the program slow to start. We hope to fix those issues in the future, with a major redesign of the Gwibber frontend.
I’m sure some OMG! readers have already seen the excellent mock-ups by Neil Patel of his proposal for a next-generation Gwibber interface.
When we implement those mockups, we are going to be using native widgets, which will hopefully help improve our performance considerably.
Additionally to Neil’s mock-ups we have seen lots of super-slick mock-ups and interface designs for Gwibber recently. Are any of these going to be adopted or used as a basis for the next ‘phase’ of Gwibber?
We welcome design feedback from the community, but we are going to be relying mostly on the work of experts like Neil and other members of Canonical’s design team.
It’s not easy to create a good design that can be implemented within the constraints of the Gtk+ toolkit. Neil has a tremendous amount of expertise in creating exceptional user experiences with Gtk+, which means that he is uniquely qualified to help us formulate a vision that is both compelling and achievable.
As far as I can tell, Gwibber is 100% Python, what challenges has this led to with distributing packages for the various distros?
Python hasn’t posed any deployment challenges on Linux. In fact, Python is extremely well-supported by all of the major distributions. The biggest problem we have with Python is that some bindings (like WebKitGtk, for example) aren’t maintained as well as we would like. There are some WebKitGtk APIs that we simply can’t use yet because they aren’t exposed through the unmaintained Python bindings. PyGI (the new Python binding system based on GObject introspection) is fantastic and will help to solve a lot of problems like that in the near future. We are hoping to use PyGI in the next version.
With the talks at GUADEC about integrating web services into GNOME, and KDE 4.4 introducing the “social desktop” functionality, where does Gwibber fit?
There isn’t anything upstream yet that does what Gwibber can do. One project that has some interesting potential is libsocialweb, but it currently only supports about 5 percent of Gwibber’s total functionality and has some serious architectural limitations that are untenable for us, like only allowing one account per service.
The libsocialweb developer has expressed some interest in accommodating Gwibber’s requirements, but it’s still a long way from being able to do what we need. If some framework materializes in upstream GNOME that is on a trajectory to be suitable for Gwibber, I’ll be very happy to contribute to it and rearchitect Gwibber to make use of it rather than Gwibber’s own backend daemon.
Because Gwibber’s frontend and backend are independent, it would not be difficult for me to totally replace the backend with an alternative if something substantially better comes along. Maintaining the backend and keeping up with changes to the APIs requires a huge amount of effort, so I think it’s good to move that kind of work upstream to the greatest extent possible so that the burden is shared between client implementers.
KDE’s Social Desktop initiative has no overlap at all with Gwibber. It’s designed to enable desktop integration of open source community Web sites, not mainstream services like Facebook and Twitter. I have experimentally added support for the KDE Social Desktop protocol (which is called Open Collaboration Services) in Gwibber, which made it possible to do interesting things like search GNOME-Look.org directly from the Gwibber client:
As a developer of desktop applications, how do you feel about the spread of services like OAuth and openID which require you to integrate to some extent with the browser to properly authenticate
OAuth is absolutely vile. It is a very poorly-designed standard that has a number of serious technical limitations. It is fundamentally impractical for use in desktop and mobile applications. Some social networks like Facebook and Google Buzz have extended OAuth with non-standard extensions in order to make it usable on the desktop, but some social networks are doing it very wrong. Twitter, for example, requires applications to embed an OAuth secret key. This is problematic, because there is no way to guarantee the secrecy of a key once it is included in software that is distributed to end users. When the key is compromised, Twitter will invalidate it and lock out the application.
This is going to pose very serious challenges for open source Twitter clients, because we have no way to even obscure our keys. Twitter promised to deliver a special authentication mechanism for open source client applications, but was not able to get it ready for widespread use in time for their transition away from basic authentication. Twitter’s decision to turn off basic authentication without first addressing this issue is very bad for Linux users. There is an extremely serious risk that open source Twitter clients will be remotely disabled by Twitter. All we can do is embed the keys in our applications and hope that Twitter doesn’t notice.
OK that is depressing! Do you mind some fun hot or not questions?
You can try asking, but I can’t promise that I’ll answer all of them. :-)
Fair enough, so hot or not?
Windows XP
Ryan: Not!
Windows 7
Ryan: Warm
Steve Ballmer
Ryan: Totally Insane
Me: I like his haircut
Seif Lotfy
Me: (SOME THREATS)
Ryan: The genius Zeitgeist developer? Totally hot!
Me: More like sexy fluffy
Steve Jobs
Ryan: Obnoxious.
Me: How do you like the fact that I placed myself between Steve and Steve?
Ryan: LOL!
Me: Its because we share the same haircut ;)
Mark Shuttleworth
Ryan: I think that Mark means well and is genuinely interested in elevating the Linux user experience.
Me: So hot or not?
Ryan: Hot!
Me: Bathing suit hot?
Ryan: not answering that.
Ubuntu
Ryan: Hot!
GNOME Shell
Ryan: I’m going to withhold judgment of GNOME Shell until it’s more mature.
Seif: Good idea. I can’t get in trouble for talking smack. You can =P
Unity
Ryan: Hot!
Seif: I took off my shirt just thinking of it.
Zeitgeist
Ryan: Hot!
Seif: You bet your ass it is… see and this time i did not have to threaten you!
Telepathy
Ryan: Hot!
Seif: My personal favorite desktop service.
OMG! Ubuntu!
Ryan: Hot!
And last but not least I think you are hot.
Ryan: LOL What?
Seif: Nothing…
So anything else you would like to users to know about?
We have some great features coming in Gwibber 3, including support for Google Buzz, Twitter lists, Ping.fm, inline images, and direct messages. It will be out with Ubuntu 10.10.