There are very few women in openSUSE for a variety of reasons. In our perceiption, despite the good efforts of moderators on IRC, forums and mailing-lists, some attitudes there still persist, and we believe these are a key issue that keeps women away. To further address this as a small group, we decided to start at just one place, opensuse-project@. Here’s why and how:

There is quite some research on why there is so few “women in FLOSS” in general. One of the recurring topics there, and one that we also quickly came to in the BoF, was the ‘flaming’, or more generally, the negative possibilities of the direct, unfiltered yet anonymous communication on IRC, forums and mail.

We all value the speed and positive directness of those forms of communication — however it’s cutting off facial expression and physical reaction. So it’s very easy to miss the tone, without even noticing. To more sensitive souls, this is creating a barrier of entry that especially women do not want to cross, or if it hits you unprepared, will reject you, often with no return. Nota bene: this effect is not limited to women! It just happens to reject women more than men.

What’s going on there? On one side there is newcomers wanting to learn, and with a great potential to contribute, however with a “thin skin”, an expectation of being treated with respect and politeness, whatever that means. On the other side, there are knowledgeable people, often young, sometimes unpatient, maybe tired, frustrated themselves. Now the former ask naive questions while the latter “shoot out” a quick response without any visual feedback on what happens right after they hit the “send” button. Kazoom! And the frustration results into discussions that quickly are far beyond the original topic, frustrating, unproductive and the opposite of what we want: respect and getting things done.

openSUSE, like many other open source projects, has set the direction for mutual respect by working out Guiding Principles, and making members accept these. The openSUSE project Board is forming a body of volunteers who “enforce” these rules, something like the Community Working Group in the KDE project. The objective is to focus the speed and directness of the communication on productivity: turn the flaming energy of frustrations into creative energy that makes openSUSE a place to enjoy and to contribute to!

We, the BoF participants, want to simply support that effort, by working on just one list (opensuse-project@), and by providing additional material that complements the very high level goals set forth in the guiding principles.

Stay tuned

xml is great:  It’s a simple, human- and machine readable serialization.  And xml sucks because of all these ankle brackets.  You need a tool to edit it.

Now yesterday I’m getting this mail:

Subject: ANN: Serna Free XML Editor Goes Open Source Soon! Help Us Build the Community!
From:  Syntext Customer Service <XXXXX@syntext.com>
To: Susanne.Oberhauser@XXXXX
Date: 2009-06-17 17:11:26

Dear Susanne Oberhauser,

We are happy to tell you that our Serna Free XML Editor is going to be open-source software soon! Serna is a powerful and easy-to-use WYSIWYG XML editor based on open standards, which works on Windows, Linux, Mac OS X, and Sun Solaris/SPARC.

We love Serna and wish to share our passion with anyone who wants to make it better. Our mission is to make XML accessible to everyone, and we believe that open-source Serna could enable much more users and companies to adopt XML technology.

It goes on about spreading the news and supporting the transition from just cost free to open source.

I got this mail because I’ve tried Serna five years ago, on the quest for a decent  Linux xml editor.  Back then it just rendered xml to xsl-fo with xslt, and then you edit the document in that rendered view, as if it was a word document.  Serna came with docbook and a few toy examples like a simple time tracking sheet.  Meanwhile they’ve added python scripting, dita support, an “xsl bricks” library to quickly creaty your own xslt transforms for your own document schemes, and the tool gathers the data from different sources with xinclude or dita conref and stores the data back to them and on the screen you just happily edit your one single unified document view.

I just hesitated to build an infrastructure around it because it was prorietary.  I hate vendor lock-in.  And now they want to open source serna!!

If this comes true, serna rocks the boat.  It’s as simple as that.  With the python scripting Serna is more than an xml editor:  it actually is a very rich xml gui application platform, with one definition for print and editing, with wysiwyg editing in the print ‘pre’view.  I dare to anticipate this is no less than one of the coolest things that ever happened to the Linux desktop… Once Serna is open source it will be so much simpler to create xml based applications.  I guess I’m dead excited

Serna, I whish you happy trails on your open source endeavour!!

S.

I wished SUSE did handle such transplants gracefully, maybe for the same reason I do not wish my 2CV back:

My first car was a Citroën 2CV.

On some summer day I did a very long autobahn trip with it and the engine got real hot as it was air cooled.  When I finally had arrived in my home town late at night, I rolled down a long hill using the engine brake and at the end of hill at a red light I stopped the car — and oops: so did the engine…

No way I could get it working again 8( None of the normal 2CV tricks worked, playing with the choke or
anything.

So I called the ADAC (AAA in germany, for those abroad), and back in the days that meant going and finding a phone box and all, in the middle of the night.

And when the guy finally arrived, the car just simply started.

I was explained to better not use the engine brake after long trips, or to carefully play with the gas when I really stopped: because somehow, don’t ask me for details, in these circumstances the spark plugs could become ‘wet’, and after they had ‘dried’ again, all was just fine.

Was I really too dumb to use my car?

No.

The car had a construction problem. Any ADAC ‘angel’ knew it.
Common sense.

I, however didn’t.  How should I?  And for the first time ever, on this day at 2:30 in the morning I really, really hated this nice little car whose sound I still love.

Same goes for Linux and hardware support.  With every single kernel update on 11.0 I had to re-tweak my wireless — and I even didn’t modify the hardware!

Now what happens if you take a working Linux install and replace some of the hardware, like the graphics card?  Or even worse, you take the hard disk of the system and put it into another chassis, like I had to do with my laptop recently?

After such a brain transplant, the the brain needs to accommodate to the new environment.  It needs to probe where it is now.  It needs to be able to access the hard disk, interact with the user, connect to the network again.

However SUSE’s not really prepared for that yet:  the initrd has the drivers it was created with last time, and that’s the ones needed for the hardware config at that time.  Hopefully the disk is accessible with what you have there… Even if the kernel can access the disk, maybe some key drivers for the new hardware aren’t installed on the disk, like graphics, or network.

Obviously you can’t make it work under all circumstances, the point is:  As of today, it won’t even work under many straightforward circumstances.  So you want to change hardware?  Better know exactly what you’re doing and don’t expect much help from what’s on your disk.

This brings me back to where I started this blog:

The factory thread had started with a plain vanilla feature comparison and soon got into a strong discussion whether or not Linux should handle brain transplants and hardware replacements gracefully at all, in a way that works for the simple minded, straightforward Linux user, in contrast to him who knows his ways around run level 3 and sax2 to reanimate X.

And I believe choking on a wet spark plug isn’t cool any more.  Linux should just diagnose and repair itself, or at least tell clearly how to proceede.

Not only because this would make mass deployment and fast installation a real charm, with a single image to boot and run on many different hardware configurations.

But also because people just do transplant computer parts and brains these days, and they want their Linux to survive that with a smile :).