That’s it. Xubuntu 12.10 is out! Download it now!
Only a week and a half until UDS-R and planning the next release of Xubuntu too. Copenhagen, please be prepared for some hard working by the Xubuntu team (or at least, three of us). If you are coming to UDS, don’t miss the Xubuntu sessions to be announced later. You can also participate remotely, if you aren’t able to make it to Denmark. Read more from the UDS website. We will post more information on how to take part on the planning inside and outside UDS later.
By chance, another friend of mine is around Copenhagen too on the same week for another event. Sounds like an evening out together!
Also, see the blog article by Mark about the codename for R: Raring Ringtail. Though I really think that Roaring Rabbit would have been better. I wonder if flavors can have their own codenames…
Thanks to Tero Karvinen, I kept a guest lecture at Haaga-Helia on their Linux as a server course. I didn’t really talk about servers but about my experiences and work with open source, especially Xubuntu.
I had prepared slides for the talk partly based on my article about benefits of open source and I did talk for almost an hour just going through my notes, but still there were some aspects that I only understood (better) when giving the lecture.
Open source projects and self-management
In addition to the fact that you can work with anything you like, whenever you like and however you like, open source projects can actually give a good opportunity to learn self-management. This is true especially with projects with time-based releases, because every deadline is a deadline.
Even if the deadline was a soft deadline and your feature or fix isn’t release critical, you should still try to schedule your work so that you will meet the deadline.
Every time you fail to meet the deadline is an opportunity to learn. The most common reason to have failed to meet a deadline is too little scheduled time. There are several possibilities why this might have happened, and some of them are more less out of sight, if you’re inexperienced. Here’s a few that came to my mind with some suggested solutions.
You didn’t start early enough and/or overestimated how productive you are. Start early and divide your project into smaller tasks, and try to work on the tasks constantly. Long breaks are bad, because it’s too easy to procrastinate just one more day. When you get back working with your tasks, it’s easier to focus on it when the thing is in your working memory.
You didn’t have enough motivation to get everything done. Make sure you don’t undertake too large projects. It’s more useful for the community too if you take a small task and finish it than take a big task but only give promises.
You weren’t able to estimate how much bureaucracy, human relations and other community and communication related activities around your task took time. It is not always trivial to estimate how much communicating or reaching the right people can take time, even if you were really experienced. The most important thing is not to forget that you do need to work with other people and that it will take time, sometimes even more than implementing the feature does.
You didn’t remember to put aside time for testing. A feature or a fix isn’t release ready if it isn’t tested. Realize that in development, release dates aren’t deadlines for new features.
Meeting the deadline isn’t bad either, because that implies you’ve already learned something. And you will actually get your name on the credits.
I can guarantee any and every employer will see it as an advantage that you are able to schedule your projects and work independently and especially deliver on time.
Working with people
I didn’t talk about this too much during the lecture and I already knew social skills are one of the most important things in, well, life. However, I did see how students can benefit seeing how different teams work.
Open source developer communities are like any teams in any workplace, except that they are usually more dynamic, because people come and go. The dynamic nature of open source communities also means that it’s easier to walk away if you disagree with others, but that doesn’t mean you should.
If you are persistent enough, you can learn how different teams and people work together, including but not limited to how to argue and rationalize your opinions, how to resolve disputes, how to let go, when to let go and when to stand for your cause. These are all qualities that you will need when working with other people, whether you are paid for it or not. Using these qualities wisely will also eventually earn you something that everybody is always longing for – acceptance.
Developing social skills is an ever ongoing challenge for all of us. There’s no other way than recommend to start working to develop the skills before you effectively need to.
This article is part of the article series On open source and freedom.