SEP
28
2007
|
All is in the community.As you probably know, I work on KOffice. Have been doing that since before the first release and I did most of the (flake)libs and KWord work in the sprint to the upcoming Koffice2.0 release. A big reason for working on KOffice is that its fun! Another, at least equally big reason is that I believe KOffice is the best open source office suite for the long term. And so follows the question; What makes a successful open source project?. If we look at what others have said on the subject we come to the conclusion that the things that count most are these 3 points;
Today I want to highlight the "community" part, as various others have been doing on blogs in the last couple of days. Without community there is no future in the project, since new contributions come from the community members. So without community the new contributions (code/docs/bugreports) dry up. Its that simple. Sustaining a community next to creating great code is a balancing act. What I love about FLOSsoftware is that you can create a great piece of work and others will try to build on top of it, including improving your code. The most obvious way of doing that is reporting bugs, but a lot of people are actually providing feedback on your work as you do it. Which creates a really great atmosphere of working where you create stuff that you could not have created were you working on your own in a closed source setting. I always appreciate people giving constructive feedback on my work. As a stark contrast I have been getting more bothered by the rise of people that seem to feel that just writing code is good enough. If someone feels the need to provide constructive feedback, or just even ask why a certain solution was chosen I have been amazed by the responses such community members write. It tends to be along the lines of "This is my code, let me do what I like in peace!" You might have seen this yourself, but examples always help (removed all names for obvious reason). Edit; it turned out that using two real life examples was not a good idea, I removed them to refocus this article on the real content edit. If you have the attitude that you don't question other people you will naturally see the very healthy and normal open source attitude of peer review as personal attacks. For the simple reason that the only reason you would ever discuss items is if you disagree with them. So others must obviously disagree with you if they ask you about your work. These two ways of thinking (the collaborative and the "I do my part" ways) are obviously in conflict. Whenever differently minded community members meet bad emotions and disruptive events happen. I've been in a couple of those in the last month and I can tell you they are very much draining me of my creativity. What do you think we can do to improve this situation?
|
![]() |
Comments
Howto accept criticism
That's funny i just read "How to Accept Criticism with Grace and Appreciation". And i know most people won't follow it, but those who do will only get more out of it.
good article indeed!
I googled for it and she writes a lot better then I do :)
Find it on zenhabits.
This is the core of my point as well;
How do you deal with criticism? I think the first reaction for most of us is to defend ourselves, or worse yet to lash back.
And yet, while criticism can be taken as hurtful and demoralizing, it can also be viewed in a positive way: it is honesty, and it can spur us to do better. It’s an opportunity to improve.
Its that lashing back that I have problems with, and her writing hopefully reaches many people in our community. Create more visibility to the problem.
Thanks for that pointer bartv!
Taking and giving feedback
Taking and giving feedback have to be learned. The latter as much as the former.
If you voice criticism in a way which makes the subject feel under personal attack, you're in for a fight. They won't respond to the criticism perse, but to the perceived threat on their person - emotions take over.
Now the way someone takes criticism depends also on earlier experiences. If you humiliated that person, or disrespected him/her/ or his/her work in the past, they quickly interpret criticism, esp if careless and harshly written, to be personal instead of technical.
And be honest - before you critique something, you (and I don't mean YOU but "most ppl") often think "what a stupid ass", right? Well, don't think that thought won't be noticeable in your reaction. You can say it was meant to be technical, just constructive, but the thoughts you had will often come through as well.
It sucks if ppl don't take feedback the right way, but that's often as much the senders fault as the receivers.
conflict resolution on a weblog :-(
Please try to resolve your conflict, which is I think mostly technical, in another way. Weblogs are amazingly unsuitable for this kind of conversation.
-- sebas
Thats not what this blog was about
Hi Sebas,
it may be that people focus on the examples first and foremost, which is not the intention. This is not about these two examples in any specific way, this is about having a growing number of people in our community that make it very hard to enjoy working together.
So, I disagree that there is any technical conflict to resolve. I'm sorry about the confusion that the examples caused; I'll remove them from my blog. Please do read the blog again and focus in the real problems I hope we can get feedback and solutions for.
Thanks!
I guess you were the person
I guess you were the person involved in one of these conflicts.
The examples were perfectly legitimate and "All similarity to real persons or events is completely unintentional."
No, he wasn't. But using
No, he wasn't. But using real-life examples might not be smart in an inflamatory situation like this (and it's good Thomas removed them).
community woes
There are always jerks, as there are always elitist jerks.
When community is small and consists of group of dedicated people, who literally know their sh*t and have common vision, all is well.
Once the project gains more popularity and becomes visible to untrained eyes of all dancing, all singing mud of the world - there come people with attitudes.
This is in human nature and you can do nothing about it, unless you have one million years and endless patience at your hands.
Good for us, percentage of such people is not very big (and most of them work on GNOME anyway, hehe).
When I encounter such people, I try to explain them only one time, why and how my fix is ok and what it makes for bettering the software. If they don't listen - I just stop submitting patches to them. Yes, this is overall worse for the community, but I can put up my patches on the web and if people like them - they pick them up, add to build scripts for various distros and so on. The best thing about FOSS - really useful things rarely die in vain.
And I don't submit patches to GNOME software at all, anymore.
-- keep in touch. berkus.
Calligra Plan
Hi Thomas, I came here to say that I think Calligra Plan is the best Project Management tool I've ever used. The workflow is impeccable!