A new star is born: Planet eZ publish is now part of the blogosphere. There you will find aggregated blog entries of community and eZ systems crew members, writing about eZ-related topics. The aggregator is actually based on eZ publish and created by my nice colleague Lukasz Serwatka.
If you like seafood, this one is easy to prepare and tastes very well:
My friend Nir Yariv started blogging. I’ve enjoyed good times with him while travelling Germany and Austria together during the Enterprise Open Source roadshow, and also during a great evening in Munich’s pub Alter Ofen.
Check out Nir’s Blog, because the dude‘s got something to say 🙂
The LinuxTag 2006 will have three focus topics, one of them is “Information Web”, which comprises CMSs, Wikis, Weblogs, etc.
If you got something important to say about this topic in English or German: the Call for Papers will end this Sunday, January 15th – only 3 more days!
After organising last year’s OscomTag subconference at LinuxTag 2005 together with Markus Nix, the LinuxTag organizers asked me whether I would like to lead the team preparing the Information Web track this year. After contacting some of the OscomTag 2005 speakers, we got together a great group of 10 people:
I am very much looking forward to enjoying this event from May 3-6!
The Call for Papers of eZ publish Conference 2006 will end in a week, Monday, Jan 16.
Hence, you can still submit your proposals in time.
I live in a tiny little village called “Bergerhausen”, which is part of Biberach. We had quite some snow lately and here are some freezy cold pictures.
Shadow on the snow: my wife and me.
View from my home office onto almost all of Bergerhausen.
That’s the house we live in, right where the windows in the roof are.
South-eastern view from my home office at the winter morning sun.
To understand the difference between commodity products from the industrial and those from the knowledge sector means to understand the main difference between the industrial and the knowledge society – and why Open Source is cutting-edge.
First of all, when talking about a commodity, I think of a product for the mass market. Many software applications have indeed become commodity products, e.g. a well-known operating system. In respect to Open Source software, being a
commodity has been identified as one of three key factors for success.
Software is a knowledge product, when you compare it to industrial commodities, e.g. doormats, is there any difference? The answer is that industrial commodities are physical goods and each new product will take resources to manufacture it. Hence, you always encounter the trade-off between quality and quantity with industrial commodities.
Quite different with software, as this is a virtual product. Software can be copied for almost zero cost, but developing it is a complex and time-consuming task. There’s actually no trade-off between quality and quantity when talking of software commodities and physical goods. The only trade-off concerning knowledge commodities like software is between quality and time.
Concerning industrial commodities, there’s a copy-per-time ratio, because the amount of products you can create, is limited by the time it takes to manufacture each product. On the other hand, knowledge commodities have an optimization-per-time ratio. There, you don’t have to invest time to create copies of the product, instead, you can invest your time into making the product better.
Due to the optimization-per-time ratio of knowledge commodities, the key to success for a software company is that it optimizes its optimization processes. Knowledge companies have the fear to become mentally lame and not agile enough to compete. In other words: they should take care of their potential to optimize the optimization-per-time ratio.
One measurable example would be more bug fixes in shorter time, but still, this would not say anything about the quality of the patches. High quality expectations need to be a natural part of every knowledge company and its organizational form and company culture needs to support every single employee to live up to these expectations.
Open Source companies and projects provide an open ecosystem to gain maximum optimization of their software commodity products, e.g. by bug fixes and new features contributed by third parties. In proprietary companies, the ecosystem is rather closed and they need to rely on internal resources mostly.
Now, the next question would be, whether the open or the closed ecosystem of optimization is more efficient and competitive? Let’s deal with it in another blog – this one is already long enough.
Here’s your early x-mas present: the eZ components beta2 are out! Seems like our developers had a lot of fun working on this release – that’s the impression I get from Toby‘s article and blog entry. When studying the changelog, it becomes clear that they put quite some effort into making this release useful for early adopters.
It makes me extremely happy to see the good development of the eZ components, as this is state-of-the-art PHP 5 development – right what is needed to showcase PHP’s OO-power. Now that the inline docs are available online, the clean design and implementation becomes obvious.
If you love to live cutting edge with PHP 5, check out the components and work with them. There are also Powered by eZ components logos available if you want to show off as a beta geek 🙂
Oh yes, and there’s #ezcomponents on irc.freenode.net now!
Mailinglists are quite useful as a part of daily project management. The way I use them at work is that I post rough ideas to the relevant internal mailinglist. Then my colleagues contribute with their ideas, comments and critique.
If the outcome of all the discussion is that we agree on actions and I am the one in charge to do and/or manage the implementation, then I simply group all emails in my Thunderbird inbox by the subject of the mailinglist discussion. This allows me to extract tasks from the discussions, which I store in the task tracker.
Now, I can keep track of every single issue by assigning each task to a category, giving it a priority, defining a due date, etc. Certain tasks might require some more discussion or consulting with other team members, which is done in the relevant mailinglists again – and this is where the process starts again.
In a nutshell, the approach is:
This seems to be quite simple and obvious, but in fact requires some sensitivity. The inital idea you post to the mailinglist, or the single task you want to discuss in more details, needs to be focused – otherwise you will end up with broad discussions that have no or too many results.
Then again, even a focused initial posting can lead to general questions. Either you moderate the discussion to become focused again, or you take up the raised issues because they might be critical, e.g. being a showstopper, or unclear responsibilities, or being of higher strategic importance.
As you are the one who raised the initial issue in the mailinglist, you should always feel responsible for the thread to be of value to others. Then you will automatically only post stuff which is important. On the other side, you can well invite others to help you become clear about certain problems if you got stuck.
Mailinglists are an excellent mean to distribute information within a team or even accross teams. In an ideal situation, they help to find solutions and make decisions jointly, something that fosters the support by each team member to actually implement his tasks.
The problem lies in a potential information overload, that too many people discuss too many issues in a mailinglist. The best way to avoid the overload is to apply the above mentioned communication skills.
As “overload” is also a subjective impression, it can help to learn how to quickly scan emails without reading them in details, to first spot whether they are actually of interest to me. The more subscribers are able to apply this skill, the more quality the conversation will get, as irrelevant postings will not get attention.
If in doubt, it is always better to have communication, even if too fuzzy and too much, instead of cutting it off. The question is how to canalize it in a productive way.
Of course, you can also apply the above said to other communication channels, e.g. forums or IRC chat. They all have their own characteristics though. A forum servers like a knowledge base automatically, similar to a mailinglist archive. Quite different compared to mailinglists, forums are not a push medium, but rather a pull medium, because you don’t get the information automatically to your email client’s inbox.
Using mailinglists as a part of project management requires an open company culture to be of benefit. This includes team members who are not afraid of telling their opinion with the risk to be challenged by others. In other words, they need to be adaptive.
In the end, being adaptive is the key of successful communication when implementing a project. Just remember that as a little baby, you were basically only able to screem. Today you can read (I asume so, because you read this blog) – and there’s always more room for the improvement of your communication skills. The main problem seems to be though, that most of us don’t remember the times when they were a baby and think that they’ve been born with ready-made communication skills 🙂
In Knowledge Management, there are the concepts of codified and personalized knowledge. Wikipedia describes it as
codification vs. personalization – the trade-off between capture and storage of explicit information and making connections to people who know.
This definition was missing the fact that personalization also refers to making external knowledge part of your knowledge, thus I added “as well as to acquire external knowledge yourself” to the Wikipedia page.
Anyway, what I wanted to say is, that it struck me again some days ago, how nicely the personality of one person or a whole group can show up in software. The way how a routine or API is designed can tell a lot about the personality of a programmer and his team:
This is what you can call “codified personality” – it is what you can also find in arts, in books, paintings, music, etc. Thus, the “vs.” in Wikipedia’s definition of “codification vs. personalization” is not totally correct, because the two concepts are not only opposed to each other, but can also go together nicely.
Of course, it is only a small step from here to ask: If personality is immanent in code, can code change the personality? Strictly speaking, code cannot change a personality, but as code is always the result of humans, it is the social system that those humans live in, which influences their personality. It is not the code that changes the personality of a person or group, but rather the way how the code is treated within the social system you belong to. As software code is codified personality, this is indirectly about how your social environment treats you.
Think of open source and proprietary as social (sub-) systems, and you’re encountering another interesting question: How do software licenses, as part of the regulatory system of your company, influence your personality?
Sandro Groganz 