Wednesday, October 29, 2008

Re: It's Time for a FOSS Community Code of Conduct

Bruce Byfield's article, It's Time for a FOSS Community Code of Conduct, has sadly made me aware that this particular problem is more widespread than I thought.

To Aaron Saigo & the rest of the KDE team: just keep rocking, dudes. Eventually these donkeys will either give up or be committed to mental institutions (or better yet, they'll cross paths with someone just like them and get what's coming around).

To the people out there attacking developers/projects:

Like I blogged a few years ago, rampant fanboyism is fine so long as you can keep it positive. You aren't doing the project you support any favors when you badmouth the other projects.

For example, GNOME devs aren't pleased when they see GNOME fanboys attack KDE all over forums or on news sites.

I'm sure the KDE devs feel the same way.

24 comments:

Anonymous said...

For example, GNOME devs aren't pleased when they see GNOME fanboys attack KDE all over forums or on news sites.

I'm sure the KDE devs feel the same way.


Eh, I'm afraid not. Just look at "segedunum" and it's years old campaign against every thing gnome on a lot of news sites, forums, etc.
"segedunum" regularly attacks gnome developers on aseigo blog and aseigo never felt anything wrong with it.

Jeffrey Stedfast said...

I'll give Aaron the benefit of the doubt and just assume that Aaron doesn't support that for the time being.

Anonymous said...

Don't be so naive, haven't you see Aaron Seigo atacking GNOME even encouraging others to do it?

I'd like to live in the same raimbow you do?

Jeffrey Stedfast said...

If that's true, then I'm sorry to hear that - but at the end of the day it's best we all just get along.

Live and let live.

andreasn said...

Isn't just segedunum just a plain sysadmin who enjoys hating one desktop more than he loves another?

I'm also curious about the strategy of the GStreamer devs. Do they want the QT/KDE devs to be fed up enough with gstreamer that they'll stop supporting it as a backend? :)

iain said...

"Those who refuse to subscribe to the code would be acknowledging that they place a low priority on common goals, and therefore are not worth listening to"

I refuse to sign any code of conduct. It doesn't meant any of the above. Sorry Bryce.

And for what its worth, the KDE guys have nothing to complain about, their fanboys are as bad as the rest.

Richard Dale said...

I'm sure the KDE devs feel the same way.

Eh, I'm afraid not. Just look at "segedunum"

I don't think Segendunum is a KDE developer. Does he have KDE svn commit access? I think not.

Of course Gnome developers and KDE ones, such as Aaron Seigo, can criticize each others projects constructively, that's what peer review is all about. What I personally don't enjoy are negative and rude comments from people who don't actually do anything to help out and fix whatever it is they find wrong.

Anonymous said...

Agree completely. I do not follow Gnome or distrobashing though.

But since KDE 4 came along the systematic bashing from some KDE 3.5 users & friends has been pretty ugly.

Some of the bashing seems to be executed by people completly locked in to their own preferences and they appear to be derailed on evereything else. It's harmful to FOSS/OpenSource/Linux and there is absolutely zero gain for anyone. Perhaps it is better for them to let out steam online. "Falling down" - seen the movie?

Jeffrey Stedfast said...

Richard: Right on.

Benjamin Otte said...

Haha, naming oneself anonymous and claming Aaron is an asshole. Go back to your hole plz. (And yes I've spent enough time discussing GNOME with Aaron.)

As for the GStremaer devs wanting KDE devs to be fed up - this is completely bogus Andreas. It's true that a lot of us (am I still a GStreamer dev?) don't see the point of Phonon. That neither means we hate it (or them) nor do we flame it (or them). Wasn't quite a bit of the Phonon backend even written by GStreamer people?
Most of the flames against Phonon result from non-developers asking about it and the resulting discussion drifting into the flamewar direction almost immediately (see my blog from today for example).

Barry Kelly said...

"What I personally don't enjoy are negative and rude comments from people who don't actually do anything to help out and fix whatever it is they find wrong"

-- the funny thing is, in the commercial software world, we call these people "customers", and we try to please them, rather than ignoring them.

It's this incentive problem that I think is behind the fact that most consumer open source software sucks. The best open source software is either primarily used by corporations - who can afford to pay consultants or hire OS developers directly - or, like Firefox, has a direct incentive to please customers through revenue (Google in the case of Firefox uptake).

Ethan Anderson said...

I like to think keeping things positive is something I'm good at..

http://www.google.com/search?hl=en&q=ethana2+%22good+work%22&btnG=Search

By all means, be encouraging, leave specific feedback, but if someone else is using their effort in a way you don't feel is productive, remember that you're not at all entitled to their labor, and you can shut it. It all goes back to something most moms say:
If you don't have anything nice to say, don't say anything.

Jeffrey Stedfast said...

Barry: I think Richard meant the people who don't even use the software, have no interest in using the software, never bothered to try the software, they just attack because it's not the software they use and for some reason feel obligated to attack simply because the product is seen as competition to the product they've settled on using.

When criticisms come from the user base of the software being criticized, then yes, those are "customers" and their feedback should be examined for valid problems (although it is often hard when the criticisms seem so hateful).

As Bruce Byfield mentions in the article, part of the problem in the land of Free/Open Source Software might be that the developers are accessible to the user base, whereas with traditional proprietary software, the developers simply aren't.

That combined with anonymity and written text (which limits expression, as opposed to spoken which can better hint at the intended meaning) can result in some pretty nasty sounding criticisms that are hard not to take as personal attacks (which may or may not be what the criticizer intended).

Anonymous said...

Seems to me that for the most part, this kind of attacking behaviour is coming not from actual FOSS developers, but from the noisy onlookers surrounding them. Reminds me a bit of those parents who think kids games should be some kind of blood sport...

Aaron J. Seigo said...

> I'm sure the KDE devs feel the same way.

yes, we do.

in fact, when i see this going on i often talk to the person involved in private to try and improve the level of discourse. for better or worse, we can't force people to be civil, and some people will take offense to almost anything which makes it even more difficult. on some level, the best we can do sometimes is to just not condone it while dealing with the unfortuante fallout.

zeenix said...

If phonon was a KDE equivalent of gstreamer, I would feel pretty much like you do but that is not the case. By claiming to be "An abstraction on top of GStreamer", phonon is an insult to GStreamer and it's main goals (i-e implicitly implying that gstreamer is something very specific to Linux, which is FAR from truth).

I am quite confident that not wanting to depend on a "G" technology was the main motive behind phonon since that is what happens to other GNOME(-based) technologies for which KDE doesn't have any equivalent of, too. As an example here is what KDE developer think about GUPnP:

http://markmail.org/message/seyhhrwathxgoo4s

This guy haven't tried GUPnP at all and is concerned about it's portability and is suggesting yet another "abstraction" layer. I think KDE guys just think that all "G" technologies are non-portable and need to be abstracted. This is a very dangerous propaganda against GNOME and we must fight it.

bart said...

@Zeenix : while vice versa, GNOME has NO problem at all depending KDE technologies like.... none?

Richard Dale said...

If phonon was a KDE equivalent of gstreamer, I would feel pretty much like you do but that is not the case.

Straw man

phonon is an insult to GStreamer

Insult (to Phonon)

I am quite confident that not wanting to depend on a "G" technology was the main motive behind phonon since

FUD

I think KDE guys just think that all "G" technologies are non-portable and need to be abstracted. This is a very dangerous propaganda against GNOME and we must fight it.

The way to 'fight this problem' as you put it, is to have calm rational discussions with KDE guys. If you use language like you have in your post the isn't possible.

Thank you for providing a perfect example of what Jeffrey was talking about in his original blog comments.

Jeffrey Stedfast said...

I have to agree with both Bart and Richard.

It goes both ways, and it shouldn't be taken as an insult.

I doubt the KDE guys meant for Phonon to be an insult to the GStreamer guys.

I don't understand why it's even considered an insult that Phonon is an abstraction on top of GStreamer in the first place. Doesn't it make sense that KDE would want an abstraction layer? They want their developer APIs to be consistent and having an abstraction also allows them to swap GStreamer out later if something better comes along.

So what? They don't want to be tied to GNOME's future. It's just smart design.

zeenix said...

I think I am being punished for using the wrong terminology: "Abstraction layer". In most (if not all) places in my previous comment where I meant "abstraction" i meant to say "portability". If you read my comment carefully, you'll notice that I am not making this up now. :)

Please keep in mind that 1. english is not my native language and 2. I am a bit dyslexian so I don't always say/write what I intend to. :(

Agreed that Qt quys would definitely need some "abstraction" layer on top of Gstreamer to be able to nicely integrate it in their eco-system but not a "portability" layer.

zeenix said...

@Zeenix : while vice versa, GNOME has NO problem at all depending KDE technologies like.... none?

So is there an example of some technology that KDE had and we created a "portability" layer on top of it? I don't think so, we usually just implement our own stuff from scratch and that I think is a something very different. I am and will not object on KDE doing that.

If you are saying this, I think you didn't focus on the first sentence of my first comment here.

Leo S said...

@zeenix
"Agreed that Qt quys would definitely need some "abstraction" layer on top of Gstreamer to be able to nicely integrate it in their eco-system but not a "portability" layer."

By making a portability layer, we (devs using Qt/KDE) get the best of both worlds. It is an abstraction layer for the simple parts of Gstreamer so we are free to use Gstreamer on all platforms with a Qt-style API. However it gives us an additional freedom of using any other backend we want.

Extra freedoms for Qt devs, no negative impact on Gstreamer. Everyone wins.

"I don't think so, we usually just implement our own stuff from scratch and that I think is a something very different."

Yes, different and much worse.

Can you imagine the outrage and accusations of NIH if KDE had gone out and written their own media framework to compete with Gstreamer? That would be the ultimate NIH waste of time. Instead they wrote a relatively small piece of software so that they could comfortably use gstreamer without being locked into it. That is far far better than reimplementing something from scratch.

Leo S said...

@zeenix "As an example here is what KDE developer think about GUPnP:

http://markmail.org/message/seyhhrwathxgoo4s

This guy haven't tried GUPnP at all and is concerned about it's portability and is suggesting yet another "abstraction" layer."

First of all, the subject of GUPnP portability was posed as a question. Bart Cerneels didn't know about portability and thus was exploring options.. There was no statement that a portability layer was necessary. Stop being so quick to jump to conclusions.

But now we come to the most important point. On Oct 9th in your blog you say "Porting to platforms other than Linux. We mostly use glib, libxml2 and libsoup so this shouldn't be a huge task."

So in other words, GUPnP doesn't work on other platforms yet. However KDE does, and so Bart was absolutely correct in being concerned about its portability! And yet you become indignant that he is. When GUPnP works on Linux/Windows/OSX, then you can be indignant that people don't think it is portable. Maybe it's simple to port, but the fact remains that it isn't ported yet. Until it is ported and proven to work, it's not exactly an option for KDE.

zeenix said...

Ouch! i had completely forgotten about the discussion here.

Leo:

So in other words, GUPnP doesn't work on other platforms yet.

So who is jumping to conclusions now? :) I didn't say that at all.

Maybe it's simple to port, but the fact remains that it isn't ported yet.

Wow! yet another jump to a conclusion. When did it become a fact?

Until it is ported and proven to work, it's not exactly an option for KDE.

You are assuming that there is a UPnP library that *is* portable and is as good as or better than GUPnP in other ways.

The word under discussion here, "portable" means something that could be 'easily' ported not something that just works on all platforms out of the box.

My point was not that GUPnP is known to be not portable but that *if* it doesn't work on other platforms out of the box, it should be relatively easy to port it to those platforms. At least it will be a much productive effort to port it rather than creating yet another portability layer, especially keeping in mind that this time (unlike gstreamer) there aren't nice (by that i mean something that has nice and simple API, uses mainloops to wait on sockets rather than launching lots of threads etc) libraries available for all platforms.

Code Snippet Licensing

All code posted to this blog is licensed under the MIT/X11 license unless otherwise stated in the post itself.