Modifiying GStreamer pipelines in PLAYING
Recently there has been some discussion in the Jokosher team about creating an abstraction for our main GStreamer pipeline. Jokosher is probably one of the most complex Open Source GStreamer applications out there right now, and managing the state of the pipeline is becoming complex. In GStreamer the pipeline has different states – `NULL`, `READY`, `PAUSED` and `PLAYING`. These states indicate what the pipeline is doing – `PLAYING` plays the audio as an example. We were under the impression that only certain states allowed modifications to the pipeline, so all pipeline modifications in Jokosher happen in `NULL` or `READY`. So, Laszlo, the King Of Cairo and Canadian Supreme has been working on something known as the ‘GP’ – the Grand Pipeline. Its an abstraction that means we have controlled access to the pipeline and the states would be handled automatically.
Well, it turns out all this is moot. Today, in an informal discussion in `#gstreamer` it was revealed that you can actually modify the pipeline in `PLAYING`. This is a big deal. It means we don’t need the GP, and it importantly means that we can hugely simply our use of state in Jokosher – and only ever deal with `PAUSED` (when stopped) and `PLAYING` (when playing). Of course, its all theory right now, when we hack the code it may not work, but if Wim Taymens deems it so, it should work. He is Jedi.
I know the last two paragraphs are a dull-o-rama for non GStreamer people, but Google needs to be taught that you *can* modify a GStreamer pipeline in `PLAYING`!
On Trust
You know, trust is pretty important to me. I put a lot of faith in the people I trust. Much of the ethos and structure behind free software is based upon trusting people. This has always been important to me, and part of the fabric of my life, long before I ever joined our community.
As such, I take *being a trustable* person *very* seriously, firstly because it defines me as a human being, and secondly because it is a quality I look for in people and I expect to reciprocate it.
So, why am I writing about trust? Well, I have been thinking about the importance of trust in my line of work. As someone who works with people every day and deals with a number of public and private matters with our community, trust is absolutely essential. When I used to work at [OpenAdvantage](https://www.openadvantage.org/), we were a vendor neutral, government funded organisation, and this neutrality made establishing trust easier. There was no suspicion that my ethics, excitement and ambition was driven by the mighty buck – we made no money, so trust could not bought and sold.
Of course, I no longer work there now, I work for a vendor. Namely, Canonical, a company that does seek to make money. This begs an interesting question about where trust fits in, particularly as I work with our community. Where is the line drawn between the company and the community? Can my trust be bought and sold as part of my work with Canonical?
Well, no. Of course not. To me, trust is intrinsic to a *person*, no matter where they work, and with that trust comes a responsibility to the people he or she works with. I work with the free software community, and specifically the Ubuntu community, and my responsibility lies with them. It is important to remember that although I have a responsibility to work in the interests of Canonical, I also critically have a responsibility to work in the interests of the community. To be an effective community manager, the community needs to have the confidence that not only will I help pro-actively help the community and move it forward, but that I will also have the courage of my convictions, and if those convictions were ever tested, that I would stand up for what I believe in. Since I have worked at Canonical, I have been hugely impressed with the sheer prioritisation of community in the company, more so than I ever expected, so this is largely a moot point, but it is important to me that I make it clear that if a point of contention did occur where I felt the company were not making a decision in the interests of the community, I would stand up and oppose it. That is part of my responsibility to the community.
Now, I have to be 100% clear here. If such a bone of contention did occur, it would be something that would not fit with *my own personal opinion* of the ethics and direction of our community. This is not a free invitation for anyone with any disagreement with Canonical to claim that I should agree with them in their discontent as part of my responsibilities. Although I feel my community barometer lines up with the general ethos and direction of the community, there are always going to be disagreements about technology, ethics and politics, and this is par for the course with any community. We are only human, and we all share different views and priorities.
My main point here is that for someone in a role such as mine, it could be easy for a cynic to suggest that I am being paid to have an opinion, being paid to be motivated and excited about our community and being paid to prioritise my employer over my community. No one has insinuated any of these things, and there is nothing to prompt me to make this clarification, but over the last month or so I felt it is important that I outline my position absolutely at the start of my work so everyone knows where I stand. Trust is something intrinsic to me, and I can assure everyone that wherever I go, my trust and integrity goes with me. Part of that trust and integrity is being clear and transparent in my views and opinions.
I love our community, and I love the doors, opportunities and possibilities it opens. I am determined to help our community grow and prosper, and every day I wake up proud to be a member of that community. Exciting times are ahead for all of us.
Talking Heads
Great first day of the [Ubuntu Open Week](https://wiki.ubuntu.com/UbuntuOpenWeek) yesterday. My [initial smugness](https://archivedblog.jonobacon.com/?p=831) about the number of attendees was over-shadowed by the smug-overdrive that I launched into when we had over **340** attendees in some of the classes. Smugr 2.0 beta.
Seriously though, I am really pleased with how many people have come along, and our community has really worked well together to get the week off to a great start. This includes the hosts of the sessions, the IRC ops, and the many people who have helped keep the sessions on track, keep the wiki pages updated and other things. Its great when community works together like this. Thanks also to AusImage for [tiding up the IRC logs for each session](https://wiki.ubuntu.com/MeetingLogs) – we want as many people as possible to get some value out of this week.
I did [my own session](https://wiki.ubuntu.com/MeetingLogs/OpenWeek_UbuntuCommunity) yesterday which seemed to go down pretty well, and I was asked a stack of great questions. I did not have chance to get through all of them, so do come back on *Wednesday at 5pm UTC* where I will open the entire session up as a Q+A about the community. For details of how to get there, and the other great sessions [see this page](https://wiki.ubuntu.com/UbuntuOpenWeek). I am also providing a session today at 3pm UTC about becoming an Ubuntu member.
So, `#ubuntu-classroom` is the place to be, and `#ubuntu-classroom-chat` is the place to chat about the sessions. Just don’t forget the [schedule](https://wiki.ubuntu.com/UbuntuOpenWeek) and [rules](https://wiki.ubuntu.com/UbuntuOpenWeek/Rules).
We kick off with…
…**240** people in `#ubuntu-classroom` for the first session of the [Ubuntu Open Week](https://wiki.ubuntu.com/UbuntuOpenWeek). Wow!
Ubuntu Open Week is here!
Well, the [Ubuntu Open Week](https://wiki.ubuntu.com/UbuntuOpenWeek) kicks off this week and we welcome everyone from all walks of life, distros, skills, opinions and curiosities to come along and get involved. The aim of the week is to help grow the awesome Ubuntu community, and we have a fantastic menu of events lined up. This is a great opportunity to get involved.
We have sessions on all kinds of subjects including Ubuntu Desktop Team, Packaging 101, The Ubuntu Community, Translations with Rosetta, Kubuntu, Maintaining an Ubuntu Package, Becoming an Ubuntu Member, Using Launchpad, Ask Mark, The Ubuntu Bug Squad, The Ubuntu Bug Squad, LoCo Teams, Ubuntu Documentation Project, Edubuntu and recently added some more sessions:
* Patching Packages
* Xubuntu
* Ubuntu Ports
Also, don’t forget we have the Ubuntu Freshers Day on Friday. The aim of this day is that anyone with any interest in contributing to Ubuntu can come to `#ubuntu-freshers` on `irc.freenode.net` and find people who can help you get started. This is an open day for anyone with an interest in Ubuntu to get involved.
Remember, being part of Ubuntu does not have to be a technical, hardcore, programming or packaging job. You can be involved with artwork, marketing, advocacy, local community teams, documentation, translations and more. We are keen that everyone with every discipline can be a part of our growing community. If you would like to help but are unsure of how, that is what the Ubuntu Freshers Day is for. Come along to `#ubuntu-freshers` and find out more. 🙂
Finally, I want to thank our excellent community for coming together to make the Ubuntu Open Week possible. The week was organised in around three or four days, and I am immensely proud of the people who actively volunteered to be a part of the week and help grow our community.
See you in the sessions!
Ubuntu Open Week
*(sorry for the rapid stream of blog posts, normal service will resume soon)*
Recently I have been working on a series of IRC events to help get new people into our community. As such, next week (Mon 27th Nov 2006 – Sat 2nd Dec 2006) the Ubuntu community holds our [Ubuntu Open Week](https://wiki.ubuntu.com/UbuntuOpenWeek) – a week of IRC tutorials and sessions designed to encourage more and more people to join our diverse community. In just two years, Ubuntu has grown to a user base of over 6 million and a worldwide community spanning many different disciplines.
The week of events includes sessions from some of the most well respected members of the Ubuntu community, on a number of different diverse subjects, including The Ubuntu Community, Kubuntu, MOTU, The Documentation Team, Edubuntu, Translating applications with Rosetta, The Bug Squad, Ubuntu packaging, Becoming an Ubuntu member, Launchpad, LoCo teams, Ubuntu Ports and a Q + A session with Mark Shuttleworth.
The full timetable is available [here](https://wiki.ubuntu.com/UbuntuOpenWeek), and everyone is welcome. All sessions take place in `#ubuntu-classroom` on `irc.freenode.net`.
In addition to the formal events, Friday 1st Dec (the Friday in the Ubuntu Open Week) is a freshers day in which new community members and those who want to get involved in the community can come along, ask their questions and get plenty of help. This will take place in `#ubuntu-freshers` on `irc.freenode.net`. Existing community members are invited to help these new folks out.
See the main [Ubuntu Open Week](https://wiki.ubuntu.com/UbuntuOpenWeek) page for the latest details and timetable!
Thank the lord above…
…because my phone is back. Same phone number. If you know me and feel your number should be on my phone, text me with your name. I can then update my rather empty phone book. Thanks!
Jokosher: the road to 1.0
Well, Jokosher 0.2 has been out for nearly a week and we have been getting some excellent feedback. The main aim of the 0.2 release was to kick out something that early adopters could test and give us plenty of feedback about what works well and what works not-so-well. Much of this feedback has been coming to us via our excellent [discussion forums](https://www.jokosher.org/forums/), our [mailing list](https://mail.gnome.org/mailman/listinfo/jokosher-devel-list) and via [reported bugs](https://launchpad.net/products/jokosher/+bugs).
We also had some testing of 0.1 done by our friends over at [The Linux Link Tech Show](https://www.tllts.org/) in Episode 168. They even recorded a small segment in Jokosher 0.1! Many of the problems that were encountered in 0.1 have indeed been fixed, and many of the resulting issues are slated as fixes for our next release which will be a 0.9/1.0 release. I really encourage our pals there to test 0.2 and report their progress.
Let me fill you in on the plans for our next release. Our 0.2 release contains all of the major features that we want to be in our first major release, but our plan is to (a) get Jokosher rock solid stable (b) make sure it works with distro released versions of GStreamer and (c) plug the remaining bugs and usability issues that are being reported. 0.2 shipped with no critical bugs that we could find, but there are lots of tiny little fixes that we want to merge in. We are slating late Feb/early March as our release time, and it will be all hands on deck getting it rock solid. With most of the development team using Ubuntu, the release schedule is based around the next Ubuntu release so that we can get Jokosher in Universe for Feisty.
On Sunday at 2pm UTC we have a meeting in #jokosher on irc.freenode.net to decide what exactly is going into our next release. Again, these will not be major new features, but will instead be refinements and fixes. We will also judge what goes in on what it touches. If a certain feature requires dramatic changes to GStreamer, this involves a longer rev time, so it will probably not go in. If it is a feature that just relies on Python and GTK/Cairo, then we can get it in. We are really keen that 0.9/1.0 will work in all major Linux distros out of the box.
This is an exciting time for the project. I am utterly amazed at how far we have come, and I have huge respect for everyone who has been a part of the project. We set ourselves a pretty audacious task with this project, and one that has required a lot of learning, testing and refinement, but we are making *real* progress. Its funny to think that when we started the project, none of us had really used GStreamer, only some of us had used GTK/Cairo and some of us were new at Python. It really shows what is possible with community and the GNOME platform.
We are all psyched up and ready to kick the world of audio recording in the balls and make it easier, more powerful and rock harder. If this gets the hairs on the back of your neck standing on end, come and join us and lets make the next release a *real* example of free software and what it can do.
The experiences of a technical author
You know, jet lag sucks. Jet lag combined with ill health sucks even more. As such, I woke at 4.30am this morning, wide awake. I headed into our company IRC channel and got chatting to some others about writing books. It struck me that this kind of discussion could be useful to others, so I figured I would *totally blog about it* (said in tacky American accent).
Writing is a funny old game. These days it seems every man and his dog have a book deal, and at pretty much every conference I go to, people are talking about getting their chapters in on time. This is understandable. Writing a book says something about you – it demonstrates an astute knowledge, a drive and an ability to convert complex concepts and subjects into a language that others can understand. Not only that, writing a book shows how you can organise and structure your thoughts effectively. Eloquent those reasons may be, they are *not* why people write books. People write books for ego. They write books because writing a book has a lot of *wow* factor, and that *wow* factor wins jobs and the admiration of others.
People certainly don’t write computer books for money. The money involved in writing is pretty abysmal. An average computer book will net you between $5000 and $10,000 in an advance payment, with some kind of royalty agreement when that advance has been earned. This requires a certain amount of books to be shipped, and with the computer book market struggling, you cannot guarantee that you will make lots of money from royalties. Th equivalent amount of work for the freelance magazine trade can net you two or three times as much money. This is why so many people write one or two books and then stop. They typically stop due to money reasons as well as the sheer workload involved in writing a book.
Getting a book contract various hugely between different people. There are hundreds of publishers out there, and while some publishers are very cautious about who they take on, some publishers will take on just about anyone. There are two approaches to selling books here, and most publishers take one of these two approaches. One method is to take on a limited number of high quality authors and projects, spend lots of time working on them, and spend lots of money in the reseller channel and marketing them. The books are higher quality and better marketed, but there are fewer products to tempt people with. This requires larger unit sales per book for it to be a success. This deal here is usually a large advance and smaller royalties. The other method is take on a huge number of projects with less established authors and sell fewer copies of each book with more limited marketing applied to each book. The deal here is typically a lower advance but very high royalties – you make your money if it sells. The problem with the latter approach is that there is a higher possibility of failure when it comes to these projects as the writers are less experienced and less familiar with just what is involved in writing a book. The upside of the latter approach is that those publishers are often more diverse in the subjects they cover.
Getting the contract is different for everyone, so let me outline my own experience. When I was at university, I used to do lots of uni work during the days and lots of drinking, partying and coding in the evenings. I used to go out to the pub or gigs most nights, get back in and then spend every night between the hours of 12 midnight and 7am hacking on KDE software, watching the Paramount Comedy Channel and just doing my own thing. I would then be up for university the following day from midday until 6pm. This demanding lifestyle gave me the benefits of university work (during the day), time with my girlfriend and mates (the evening) and time for my own work (most of the night). Sleep was a 7am – midday thing.
It was in the midnight – 7am period that I started freelancing for computer magazines. I remember going to the Linux Expo in London the first year at university, and I got drunk with the Linux Format guys in a bar near Olympia. It was there that I asked if I could write an article for them and they said *”sure, but if it sucks we get to reject it and not pay you anything”*. It sounded reasonable to me, so I started writing. After two years or so of writing a huge number of articles for three Linux magazines, a book agency approached me to ask if they could represent me as an author in the book trade. After some conference calls I agreed, and I have been with the same company ever since. If it was not for my crazy life at university, and the large number of articles I wrote in addition to my uni work, I would never have been approached by my agency. My experience is certainly not the same for everyone, but every author needs to prove themselves somewhere before they will be accepted to write a book, particularly if you want to write for a *decent* publisher who will actually sell a decent amount of units of your book.
Writing a book is *hard…really, really hard*. I remember when I started my first book, which was a non-starter KDE 2 project for Sams (the book came about when I was doing my final year at University, so never really got very far), I was told by my agent that *”Writing a book is one of the hardest things you will do. Everyone expects it will be much easier than it really is, but it will test your time management, technical skill and mental ability to cope with a large writing project”*. He was not wrong. Writing a book takes a huge amount of energy, and unlike freelance projects, the huge scope of a book means setting firm deadlines and making sure you hit those deadlines. When I wrote *Linux Desktop Hacks*, I divided the project length by the number of hacks I needed to write and this gave me a deadline for each hack. I also factored in a one day buffer per hack – this would account for those hacks that required extra time. Each book is different, and requires its own planning. For *Practical PHP and MySQL*, I divided project length into a bunch of milestones, but each chapter had its own PHP application that needed developing too, so I dedicated one week for coding each app and one week for writing each chapter. The key thing here is that you should *always* aim to smash your deadlines early. This always gives you more flexibility for *crunch time*.
*Crunch time* on a project is when you are nearing a deadline, and everything ramps up a notch. For book projects you will have an editor who looks over your work, and when each chapter is complete it usually goes out to reviewers. Each of these reviewers leave their opinions and comments, as does your editor. Your responsibility is to then fix these issues as soon as possible. At the end of a project, the time allocated for this process is very thin and this can mean huge amounts of extra work to get everything ready. This is particularly relevant for new authors who make a number of common mistakes. As an example, *Practical PHP and MySQL* was originally going to be an O’Reilly title, but O’Reilly vastly over-commissioned a bunch of books, and mine, like many others got the chop. After my good relationship with Prentice Hall over *The Official Ubuntu Book*, I took it there. When I originally wrote the content for what is now *Practical PHP and MySQL*, I wrote it in a very British way, fairly passive with lots of amusing quips and random humour spread throughout the book. This was very different to the largely North American O’Reilly style. As such, as the project continued to develop, large chunks of my content needed rewriting to cater for this style.
This is where a good publishing house really comes in. A good publisher will have very high quality editors working for them, who will help you get the style, tone and organisation of your book right *as you write it* instead of when you crunch at the end. I have worked with a bunch of different publishers, some of which were *shocking* when it came to editing. A new author with a good editor can make amazing books. A new author with a bad editor will make heartburn.
I know a bunch of you will have read this blog entry with interest as you are yourself keen to write a computer book. My main intention is to not scare people away from writing books, but to provide some experience of the real world issues when taking on a book project. It is an intense process, often driven by intense people, and it is not for everyone. But, if you like a challenge and you can write, it is an incredibly rewarding process. When you get your first printed copy sent to you, you feel hugely proud of your efforts. If it then sells well, it is even more inspiring. My main interest is in helping prospective authors to see the full picture and be prepared for some of the strangeness in the publishing world. Good luck!
No idea…
…why my posts are staying at the top of the various planets. I am looking into it. Sorry folks.