On May 17th I posted a request for people to submit movies and clips from the mobile phones and digital cameras to our tracking bugzilla entry. Today Wim posted a comment to the bug saying that allmost all the bugs where fixed. I think people will have some problems still due to the AMR decoding library not being generally available. If you want AMR support under GStreamer you need to follow the instructions in the README in the ext/amrwb directory in gst-plugins-bad. We are of course aware that this is a bit of a pain, but luckily doing an AMR decoder/encoder is a ffmpeg SoC project this year.
There was one file submited using a Qualcomm codec which also is lacking open source implementation. As I pointed out in the bugzilla there is a free beer library available for supporting this on desktop systems, so if someone is interested in helping us create a GStreamer plugin for it that would be a good thing for those stuch which phones or cameras using this codec.
So there are no known bugs anymore in relation to these files there is only a unimplemented codec (QCELP) and a codec which you need to do some manual compilation to get support for (AMR).
We would still appreciate even more movie clips and camera model information. I am sure there are more phones and cameras out there producing more weird files. So if you got one of those please add it to the tracker bug report
Google Summer of Code
The SoC projects are now chosen and we got some nice projects approved. Particularly happy that the updated gst-editor application got approved. There was a very good application for MXF demuxing/muxing GStreamer plugins submitted under the Xiph.org banner, but unfortunatly Xiph.org didn’t get enough projects allocated to take on this project. Not getting that project through was the only thing I am feeling a bit bummed out about as it was a really well written and thought out application. A big thanks to Marko for applying.
Open Source and Strategy – A GUADEC story
With GUADEC approaching fast I have been thinking a bit about what we do at GUADEC and what have worked and not worked earlier years. One thing GUADEC has at times been good for is to help us set some strategies for going foward. I think the biggest singlest success story in this regard is the strategic decision taken during and after GUADEC 3 in 2002. At GUADEC 3 Jim Getty‘s did a talk called draining the swamp. In this talk he pointed out some of the problems we face today and how we need to be better at reaching out to others to solve them. This talk and the subsequent debate led to some major decisions getting taken in the GNOME community.(To be fair others, like Havoc Pennington, had brought up similar issues before and even worked on them, but I think GUADEC 3 and Jim’s talk was a turning point).
The strategic choices I think can be summed up as follows:
- We need to reach out to other projects and organisations and pull them closer
- We need to fix problems on the right level not try to fix them on our level
- Focus on getting things right on Linux while making sure the solutions we choose don’t permanently lock out other platforms
- Work on cross-desktop standards to avoid redundant efforts and increase interoperability
- It isn’t our way or the highway
I think on all these areas we succeeded and the world is a better place today for it. In terms of project outreach I think we succeeded in pulling projects such as Mozilla, OpenOffice, Eclipse and Xiph.org to name a few closer with the three first all now defaulting to our having GTK+/GNOME integration as their natural Linux integration point. True enough we didn’t have any real competition in some sense with anternatives either being license wise unacceptable or already on the way out, but a lot of personal initiatives where taken by people in and around the GNOME communty to engage with these projects and I think it has paid off. Adoption by commerical vendors such as vmware and Adobe is another example of how the choice to be more welcoming to ‘outsiders’ has worked out.
As for fixing the problems on the right level this was about renewed engagement with people in the kernel and X communities for instance and in some cases pushing projects to freedesktop. This also ties in with the linux focus point. Instead of creating a forest of abstraction layers to try to overcome the problems of varying platforms with or without certain features and functionality there was a decision to choose good solutions and help popularize them instead of letting lack uniformity hold us back or cause us to waste time and effort trying to support highly different systems. HAL is a good example here. GNOME decided to go for HAL even though it was a pure linux solution at the time. The design of HAL wasn’t made to be linux exclusive, but the implementation at the time was. Up to this point we had tried with varying levels of success of working around and abstracting this away at the GNOME level. With the current work done on porting HAL to Solaris and FreeBSD I do feel that this strategy is vindicated and HAL is providing us with a much better plug and play story than we ever had before. Lesson here is that if you try to be Jack of all trades you become master of none.
After GUADEC 3 GNOME people put a lot more emphasis on trying to push more things into freedesktop.org. There was some initial pushback with people crying about freedesktop being a cover operation to force GNOME technologies onto the world and so on, but I think today most people would agree that the steps taken with freedesktop have been good and if anything we have not managed to take enough steps.
It isn’t our way or the highway. I also think that it was about this time that GNOME developers starting coming to a true acceptance that there was nothing wrong with developing applications in other programming languages and frameworks. There was a lot of discussion about what it means to be a GNOME application, like can you be a GNOME application even if you don’t use library XYZ and so on. Today we have a thriving community of developers doing applications in C++, Python, Mono, Java, Ruby and many more. Some are using GTK+ or GTK+ bindings, while other integrate much more indirectly using toolkits such as SWT, Swing, wxWidgets, XUL and VCL. We still have an ongoing job to define what we expect of a GNOME application in a more neutral fashion, but long term there should be nothing stopping someone from even doing a GNOME application in Qt for instance. The philosophy being that if it looks, walks and talks like a duck, then it is a duck. You don’t need to disect it to prove it as a duck. This is software development not biology :).
There has been a lot of other strategic decisions made over the years too of course which have had smaller or bigger impact. The HIG and the 6 months development cycle to mention a few. Or in some sense we never made any strategic decisions, but GUADEC have always played a instrumental role to ensure developer buy-in for such things, and those ideas which have gotten enough buy-in have looking back become strategic decisions :) I guess that is the sort of thing which people coming from a non-free software background have trouble relating too :)
I don’t know what will be the strategic choices made or strongly influeced by this years GUADEC, but I will be there to find out and so should you :)