As a co-maintainer of the KDE Accessibility Project I would like to give one
 or two talks about Accessibility within KDE. The topics would be as outlined
 in the abstracts below.
 
 The full content of the first talk will of course depend on how the
 applications within the KDEAP (KMag, KMouseTool, KMouth and possibly kttsd)
 in the near future will evolve and which accessibility issues we will detect
 before the conference.
 
 Currently we have different approaches for possible architectures (within the
 second talk). Which one(s) I will present in the talk will depend on some
 discussions on the kdeaccessibility and core-devel mailing lists.
 
 Gunnar Schmi Dt
 
 
 
 Talk 1: KDE and Accessibility
 
 This talk covers both the current state of the KDE Accessibility Project and 
 some general view on accessibility issues within KDE. It will also contain an 
 outline of kttsd and word completion for usage as KDE-wide technologies.
 
 
 
 Talk 2: Accessibility and Interoperability
 
 This talk will show an outline of an architecture for adding AT-SPI support
 (Assistive Technology Service Provider Interface) to Qt/KDE. As there could
 be applications and assistive technologies both within and without KDE this
 architecture needs to interoperate well with GNOME's Corba based assistive
 technology framework.

 Object Orientation offers strong concepts for functional decomposition
 of systems. There is a number of requirement types though, that can
 not be properly encapsulated into classes or functions. The reason
 for that is, that these often non-functional concerns crosscut the
 system's structure, leading to a scattered and tangled implementation.
 
 Aspect Orientation aims to provide a solution for this problem by
 offering a new modularity concept, that allows the extraction of scattered
 and tangled code fragments into first class entities called aspects [1]. 
 However, the gain of modularity comes at the price of increased 
 complexity. Dedicated tool support to reduce the complexity is therefore 
 crucial for successful emplyoing of aspect-oriented concepts.
 
 In this paper, the concepts of Aspect Orientation are introduced and
 an overview of state-of-the-art aspect-oriented technologies for C++
 is given. A case study will reveal whether these technologies are
 already suitable for adoption in real-world projects.
 
 
 References:
 [1] Gregor Kiczales, John Lamping, Anurag Menhdhekar, Chris Maeda, 
     Cristina Lopes, Jean-Marc Loingtier and John Irwin.
     Aspect Oriented Programming. In Proceedings European Conference
     on Object-Orientated Programming, volume 1241, pages 220-242. 
     Springer Verlag, 1997.

 I could do any number of the following talks at Nove HRady:
 
 * Tips and tricks for debugging (gdb, test programs, valgrind, cachegrind...)
 * How to write a Makefile.am (based on the short talk I gave at the last FOSDEM)
 * The trader mechanism (usefulness, services and servicetypes, querying, debugging).
 * How to write good network transparent code (KURL, KIO, jobs vs NetAccess).
 * KParts (how to write a component, how to find and instanciate a component, when to
 use KParts for an app's components...)
 * The KOffice framework (relation to KParts, doc/view design, embedding, etc.)
 
 Actually, I could also do a Qt course for beginners, but I don't think there will be many :)

 The dynamic desktop
 -------------------
 
 Many KDE applications are extensible in form of plugins, additional
 texts or images or audio files, or other means.
 Up to now each application has to define an own way on how to
 access these additional files.
 This ranges from requiring the user to download contents over
 predefined download sites (like kde-look.org) to embedded mechanisms
 as used in KOrganizer.
 
 In 2002, a project named KDEShare was proposed, and an initial implementation
 was started, which worked essentially but had some design issues, and since
 some timing issues were involved as well the development on it stopped.
 
 Yet it clearly shows that a unified way of updating contents is needed:
 * many applications, like those in kde-edu, come with a default set of data but
   offer additional sets (sounds, vocabulary files)
 * some applications rely on fixed host names for their updates, yet a fault
   tolerant transport is needed, which could be ensured using metaservers
   embedded in a general resource framework
   (example: KDE internet radio frontend)
 
 This talk is intended to regain interest in the topic, and to present specific
 development goals.
 Application-specific integration will be presented using KParts, application
 invocation and DCOP calls.
 Access to metaservers (and how to administrate them) will be part of the
 presentation.
 The collaboration with a typical 3rd party KDE project will be shown as well.
 

 This is to notify you that I will give a talk on Kontact at n7y. abstract 
 below. I'd like a workshop to go along with that to assign tasks and discuss 
 the further development.
 
 Cheers,
   Daniel
 
 Abstract
 =======
 
 In times where KGX is hitting the corporate desktop, it is important to have a 
 groupware enabled personal information management (PIM) client that is able 
 to interact with common groupware solutions such as Kolab and Exchange 2000. 
 
 Kontact, a collaborative effort of the KMail and PIM team tries to serve this 
 demand.This talk will give a summary on what has been achieved and what still 
 remains to do. It includes a general presentation of Kontact's features and 
 addresses technical and conceptional details, ideas and plans.
 
 Also Kontact will later on superseed the Kolab client and therefor inherit all 
 its features.
 
 This talk addresses two primary parties:
 - Developers interested in joining the KDE PIM team.
 - Companies that seek out on a native KDE integrated client for Kolab or 
 Exchange and want to get involved with Kontact development or support the 
 project.
 
 A workshop will be appended on demand, Kontact hacking will take place during 
 the hackfest.
 
 Web Reference: http://kontact.kde.org

 I want to make a presentation about using libkabc, the KDE AddressBook
 Library. I do this the first time, so I don't know exactly what this
 abstract paper should contain. If you need more information, please
 reply me.
 
 Here is the structure of my presentation:
 
 The KDE address book library
 ------------------------------
   - General concept of libkabc
   - The API
   - Small example program
   - Advanced usage
   - Implementing resources
 
 
 Maybe Cornelius Schumacher will participate, but he can't promise
 anything at the moment because of lack of time.

 I know I am late... Here are my three talk submissions:
 
 Annual Report of the Board of KDE e.V.
 =============================
 (together with Mirko Boehm, Eva Brucherseifer, and Ralf Nolden)
 - financial report of KDE e.V.
 - status trademark registration
 - status registration as non-profit organisation (re: tax deductability)
 - current events
 
 
 Be More Rational: Open Source Memory Debugging and Profiling Tools
 ====================================================
 (together with David Faure, who doesn't know of his luck yet :-))
 This talk will be similar to the LinuxTag talk with the same name, but have a 
 stronger emphasis on KDE development. We will present tools like Valgrind and 
 KCachegrind and show real-life examples and to debug and optimize KDE 
 programs in a time-efficient way.
 
 
 The History of the KDE Project
 =======================
 (together with Matthias Ettrich, who doesn't know of his luck yet :-))
 This talk, given by two participants from "Day One", will present newer KDE 
 developers with some cultural background of "how it all started": Matthias' 
 original Usenet posting, the first pieces of code, the first package, the 
 first CVS server, the famous c't article that got many of the German 
 developers to KDE, the first KDE conference "KDE One" in Arnsberg, etc.

 I thought about interesting and important issues that we should discuss (and 
 possibly solve) at Nove Hrady. Please send further input so we can organize
 that in the best way. I guess it will also be imporant for the organization of 
 the event so I prereferred to post it now that later. Note that those are 
 ideas, I am not going to organize both, the other one is only sort of a 
 reminder.
 
 1) A while back, Matthias suggested KDE integration into Qt ("KDE as a 
 supported pattform for Qt"). This is very important for the perception of 
 consistance (key word: file-open dialog, but that doesn't cover everything of 
 course). What progress has Trolltech already made for Qt4 wrt that? I'd like 
 to propose to set up a "task force" from TT and KDE developers that work out 
 a sensible plan. Should this be done a workshop? Matthias, what do you think?
 
 Type: Workshop
 Participants: TT developers, KDE developers
 Organizer: open, any takers?
 
 2) Under Windows, MacOS and other operating systems, the user is used to a 
 consistant set of tools for basic system administration. Currently every 
 distribution ships their own setup routines for that. While this is perfectly 
 fine for the setup itself, I think tools for basic system administration (at 
 least for the average set of tasks a home user has, I'd prefer DE-integrated 
 tools (I am thinking of a KControl spin-off similar to KInfoCenter containing 
 applets for (basic) system administration). Those should have backends for 
 each distributor to fit his needs (ideally perl I guess, assuming Perl 
 knowlege > C++ kowledge at most distributors). The other side is probably the 
 marketing side of things (many people buy Distributions because they like 
 their tools, so I guess many don't even want to drop sets of them for the 
 sake of something common. This also needs to be worked out.
 
 Type: Workshop
 Participants: KControl-involved/interested developers, distributors
 Organizer: so far only me. Chris, can you come/are you interested?

 i am Holger Schroeder ( holger-kde@holgis.net ), i am studying Mathematics and 
 Computer Sciences in Hannover, and i am a kde addict snce about two years.
 i am working for automatix ( www.automatix.de ) half of the time for 
 commercial projects and half of the time for open source stuff, in the same 
 way as Zack Rusin.
 
 i am mainly working on two areas in kde:
 
 - adding support for the openoffice file format to koffice. not su much time 
 for this at the moment :(
 
 - getting kde running on microsoft windows as native as possible ( 
 kde-cygwin.sf.net )
 
 i would like to give a talk about the kde-cygwin project.
 
 Abstract:
 
 The kde-cygwin project makes KDE available on Microsoft Windows Operating 
 Systems. Currently the only way to do this is to use Cygwin ( www.cygwin.com 
 ) and to use a X-server in Cygwin.
 This already works fine, but it has some drawbacks: All kde windows are inside 
 a big X window, and not directly on the Windows desktop, and only the X 
 window appears in the Windows-"taskbar". Also the X-server eats performance.
 So i started to dig into the kde and qt sources and looked for parts, that 
 were X-dependant. Then i started porting the GPL´ed qt for x11 to use native 
 Windows gdi calls. This project can be found at 
 http://kde-cygwin.sourceforge.net/qt2-win32/ . Then i got a commercial qt 
 license for x11 and for Windows, so i am not allowed to continue working on 
 the qt-win32 port. i guess i finished about half of it. All the drawing stuff 
 works, only parts of the rest are missing.
 
 So now i am able to take the KDE sources and replace the X-dependant stuff by 
 something that works under Windows or simply comment it out. There is only 
 little functionality in kde that depends on X directly instead of the qt 
 routines. it is mainly the handling of keyboard input (global shortcuts, ... 
 ), querying for screen properties ( x11AppDpiX() ... ) and the NETWM stuff.
 
 I think i will have something usable running at the meeting. Supporting ms 
 windows is a goot thing IMHO, and that would mean we have to sort these few 
 issues out in a clean way.
 
 Then there is also the issue with regard to the commercial qt license. it is 
 ok with me, when i will be compiling all kde programs for windows. but 
 perhaps people on windows should be able to learn programming with kdevelop 
 too. i think this will be a quite interesting discussion...
 
 
 <<< end abstract.
 
 i think this talk will fit fine into 45 minutes. first i would like to show 
 off, how kde looks under windows, for example konqueror, kmail, koffice. then 
 i want to explain what exactly i did to get it running, explain what in kde 
 is platform dependant and how this could be solved.
 then i want to explain what i did at the qt-win32 port, and explain what is 
 left to be done to have a fully-funtional qt for windows under gpl.
 ( if this is wanted, is another question... )

 KDevelop 3.0
 
 KDevelop started as an ambitious project to bring an easy to master integrated 
 development environment (IDE) to KDE. The upcomming release of KDevelop is a 
 big milestone for the project. The code is a total rewrite and features a 
 plugin-based language-independent infrastructure. A lot of work has been put 
 into the new version making it one of the largest KDE application currently 
 available.
 
 The presentation will feature developing with KDevelop as well as developing 
 on KDevelop. Main points reach from project generation to handling the 
 project management, version control, debugging as well as handling and 
 customizing the IDE. The focus lies on C++/KDE development, but also touches 
 scripting projects (perl, php, python) and other supported programming 
 languages like ada, java or pascal. A brief overview of KDevelop's structure 
 illustrates how easy it is to extend the IDE with additional features.
 
 Arrangement:
 
 - A glance at the IDE
 - Kicking off a new project
 - Project management with automake, qmake or ant
 - Handling version control systems
 - Debugging
 - Using the documentation browser
 - Extending the IDE
 
 Timeframe: 45 minutes talk followed by 15 Minutes Q&A
 
 Harald Fernengel , assisted by Roberto Raggi 
 

 Abstract
 
 Zero Configuration Networking allows computers and other devices to
 communicate without any manual configuration. This means that
 computers and devices on the same network must assign themselves IP
 addresses, without the presence of a DHCP server. Systems must
 broadcast their names on the network, and they must be able to
 announce the services that they offer.
 
 SLP (RFC 2608) is a proposed IETF-standard for a extendable and
 scalable service location protocol. It can publish information about
 network services in the form of a URL bundled with a set of
 attributes. In small networks SLP can work without any servers as a
 peer-to-peer system. In larger networks one or more servers need to be
 deployed. Clients will discover and use these servers automatically.
 
 The Knot is an implementation of SLP with a focus on security and
 extendability. It is implemented in C++ using Qt/TinyQ and comes with
 a powerful KDE API. Several small extensions allow to use it for
 naming as well as File Sharing with existing protocols like NFS and
 SFTP.
 
 This talk gives an introduction to the concepts of Zeroconf and its
 implementations with a focus on SLP and presents the Knot. It will be
 assumed that the listener has basic TCP/IP knowledge.
 

    Here is my proposal for a presentation on the upcoming KWallet for KDE 3.2.  
 Unfortunately I have been unable to confirm my ability to attend the 
 conference yet, but I still hope to do so.
 
 
 KWallet
 
 KDE 3.2 will include a new subsystem for storing sensitive data such as 
 passwords, web forms and certificates in strong encryption containers known 
 as "wallets".  This behaviour mirrors the behaviour of implementations such 
 as Mozilla's Wallet, Apple's Key Ring, and other similar subsystems.  It also 
 extendes these concepts by implementing generic storage mechanisms and user 
 interfaces, allowing more complex data to be stored and shared amongst 
 applications as well as allowing the user to easily manage the stored data 
 and control which applications may access it.  This paper will outline the 
 architecture of KWallet as well as discuss how and why application developers 
 should take advantage of what KWallet has to offer.  It will include examples 
 of applications presently using KWallet.

 Performance Analysis of GUI applications on LINUX
 
 
 Optimizing performance in a LINUX application is a difficult task
 using the legacy profiling tools like gprof. Especially in the scope
 of GUI applications using shared libraries and dynamically opened plugins,
 these tools are difficult to use and often can't help at all.
 The result is, that in most cases, performance optimization doesn't happen
 at all. If there's an obvious performance problem, one has to
 estimate the location of the bottleneck or resort to handcrafted
 meassurement routines.
 
 Last year, a tool for instrumenting binary code on the fly was
 released for LINUX under the GPL: Valgrind. Using its technique first as a
 memory debugging, its astonishing features and ease of use made it
 quickly the number one tool in the open-source LINUX community.
 In contrast, Valgrinds usefullness for program execution analysis is
 less known, but likewise powerful. It's based on the
 cache simulation extension "cachegrind", delivering flat profiling on
 a source line level. But to get a real overview of the performance
 characteristics of your program, the meassured costs have to be attributed
 to functions or even libraries. Also, you want to see the cost of a
 function including the cost of all the functions called from there.
 This is especially important for programs doing the real work in
 third party libraries with long call chains like GUI applications.
 Thus, call tracing was added to "cachegrind", resulting in the tool
 "calltree".
 
 To make use of the huge amount of data delivered by this tool, one
 needs a powerful visualisation, allowing for quick browsing at different
 granularities ranging from costs of instructions to summed up costs of a
 whole shared library. A tool delivering these features is KCachegrind,
 likewise released under the GPL.
 
 In the paper, first I will give an overview of techniques and problems of
 performance profiling in general, the availability of tools for LINUX,
 and how the "calltree" extension of Valgrind comes into play here.
 Then, I will show the requirements for a visualisation tool to enable
 successfull performance analysis, together with the featureset of
 KCachegrind. The paper finishes by showing the typical use case of
 the toolchain calltree/KCachegrind together with a standard KDE
 application, and the steps involved for practical use in performance
 optimization.
 
 [For the talk, depending on availability this will result in a
 live presentation]

 Accessing the internals of QObjects
 ===================================
 
 QObjects form the core of Qt and KDE and provide a number of powerful facilities
 including the signal/slot mechanism, a navigable tree and properties. While the
 public APIs provided by Qt are enough for many applications, they are not
 sufficient for all purposes forcing us to use undocumented features to implement
 facilities such as the Qt-DCOP bridge and the KJSEmbed QObjectProxy class. This
 paper discusses the undocumented features that were used to create the
 QObjectProxy, and the difficulties that were faced. It will further discuss what
 would be required to create a reusable library that conceals these undocumented
 techniques behind a maintainable API making it practical to use them more widely
 in creating bindings to other scripting languages or communication systems.
 

 I thought about interesting and important issues that we should discuss (and 
 possibly solve) at Nove Hrady. Please send further input so we can organize
 that in the best way. I guess it will also be imporant for the organization of 
 the event so I prereferred to post it now that later. Note that those are 
 ideas, I am not going to organize both, the other one is only sort of a 
 reminder.
 
 1) A while back, Matthias suggested KDE integration into Qt ("KDE as a 
 supported pattform for Qt"). This is very important for the perception of 
 consistance (key word: file-open dialog, but that doesn't cover everything of 
 course). What progress has Trolltech already made for Qt4 wrt that? I'd like 
 to propose to set up a "task force" from TT and KDE developers that work out 
 a sensible plan. Should this be done a workshop? Matthias, what do you think?
 
 Type: Workshop
 Participants: TT developers, KDE developers
 Organizer: open, any takers?
 
 2) Under Windows, MacOS and other operating systems, the user is used to a 
 consistant set of tools for basic system administration. Currently every 
 distribution ships their own setup routines for that. While this is perfectly 
 fine for the setup itself, I think tools for basic system administration (at 
 least for the average set of tasks a home user has, I'd prefer DE-integrated 
 tools (I am thinking of a KControl spin-off similar to KInfoCenter containing 
 applets for (basic) system administration). Those should have backends for 
 each distributor to fit his needs (ideally perl I guess, assuming Perl 
 knowlege > C++ kowledge at most distributors). The other side is probably the 
 marketing side of things (many people buy Distributions because they like 
 their tools, so I guess many don't even want to drop sets of them for the 
 sake of something common. This also needs to be worked out.
 
 Type: Workshop
 Participants: KControl-involved/interested developers, distributors
 Organizer: so far only me. Chris, can you come/are you interested?

 Qt - past, presence and future
 -----------------------------
 
 In my talk I am going to give an overview on how Qt developed in the
 past, what we at Trolltech have been doing lately and what our plans
 for the upcoming years are. The focus will be on topics relevant for
 KDE, such as performance, flexibility, and productivity.

 Sorry, I posted this on the nove-hrady-mailinglist. I got Info about the
 submission only recently from mails in the list.
 So please see text below.
 
 yours
 Andreas Brand
 
 Besides: I would prefer a speech at the first weekend of your meeting.
 
 > -----Ursprüngliche Nachricht-----
 > Von: anbrand [mailto:A.Brand@em.uni-frankfurt.de]
 > Gesendet: Donnerstag, 22. Mai 2003 16:22
 > An: novehrady@mail.kde.org
 > Betreff: My research about KDE
 >
 >
 > Hello KDE-Nove-Hrady-Planning-People,
 > I have read that you are planing a KDE-meeting at Nove Hrady. I
 > do not know if you remember me but I did ask you questions and
 > let some of you fill out surveys at last years linuxtag. After a
 > lot of time I have nearly finished my research. My research
 > consists of a case study, the analysis of the survey (linuxtag)
 > and the analysis of interviews from tink. The findings of the
 > case study are attached to this mail. The findings of the
 > quantitative studies could be found at
 > http://www.uni-frankfurt.de/fb03/arbeitslehre/brand_veroeffentlich
 > ungen.htm (the working papers at
 > http://www.uni-frankfurt.de/fb03/arbeitslehre/Auswertung%20Selbsti
 > nterviews%20OS-community%20V0,5.pdf and
 > http://www.uni-frankfurt.de/fb03/arbeitslehre/Auswertung%20quan%20
 > Interviews%20OS-community%20V0,5.pdf). These working papers (the
 > quantitative studies) are in a pre-beta Phase and I have seen
 > that the pdf-format has omitted something at diagrams in this
 > papers. But nevertheless I think, the findings are interesting
 > for you. If you have questions or remarks about some findings
 > feel free to mail me.
 > I am also in contact with the planing group of linuxtag 2003 for
 > a speech about these findings.
 >
 > I want to reflect/give back my research to your community. So my
 > question is, if I could give a speech or workshop at your
 > KDE-meeting at Nove Hrady (Probably the same as on the Linuxtag).
 >
 > Sorry,
 > I forgot: the texts about my research are in german. I have and
 > had no time to translate them in english. I asked my girl-friend
 > to translate the quantitative studies but this will take some
 > time (also they are in a pre-beta phase so translation is not
 > worth the effort). I hope you will understand this problem.
 > But I could hold the speech in english, so that everyone could
 > understand it.
 >
 > Best wishes
 > Andreas Brand
 >
 > Besides: It seems that there are some people who are interested
 > in the research. F.e. Stephan Binner contacted me and asked for findings.
 
 Andreas Brand: Die Struktur, Eintritt, Leistungserstellung, Motivation
 und Kontrolle in einem Open Source-Projekt
 Paper für einen Vortrag auf dem Linuxtag, 10.-13. Juli
 
 
 Kontakt:
 
 Dipl. Soz. Andreas Brand
 Project electronic labourmarkets (PELM) / Projekt elektronische Arbeitsmärkte
 Johann W. v. Goethe Universität / Johann W. v. Goethe University
 Institut für Polytechnik und Arbeitslehre / Institute for polytechnic and laboursciences
 Email: A.Brand@em.uni-frankfurt.de
 Url:   http://www.uni-frankfurt.de/fb03/arbeitslehre/StartseitePELM.html
 
 
 Struktur: 
 Innere Struktur von KDE:
 
 Bei diesem Open Source-Großprojekt handelt es sich um eine weltweit
 verteilte Gruppe von ca. 800-1000 Menschen (ca. 800 cvs-accounts ohne
 den Großteil der Übersetzer), die vor allem aus Europa, besonders
 Deutschland, kommen. Die meisten Projektbeteiligten kommen aus dem
 Kerneuropa, d.h. D, F, GB, Benelux, und einige aus USA/Kanada.
 
 Es existieren aber auch regionale Cluster, wie z.B. in
 Nürnberg/Erlangen. Die Gruppe ist recht homogen, da der größte Teil
 der Personen männlich und zwischen 20 und 30 Jahren alt ist. Ein
 großer Teil der Projektbeteiligten sind Studenten, ein anderer großer
 Teil sind Erwerbstätige. Gemeinsam ist der überwältigenden Mehrheit,
 daß sie entweder eine IT-Studium oder IT-Ausbildung absolviert oder
 absolviert hat. Schüler, Lehrlinge, Arbeitslose und Erwerbstätige aus
 anderen Bereichen bilden dagegen eine Minderheit. Z.T. gibt es auch
 mitarbeitende wissenschaftlich Tätige und Projektbeteiligte, die sich
 selbständig gemacht haben und Dienstleistungen um das Open
 Source-Projekt anbieten.
 Alle arbeiten freiwillig, als Hobby, an der gemeinsamen Erstellung
 eines Desktops. Es gibt verschiedene Tätigkeitsbereiche in der Open
 Source-Community, wovon die Softwareentwickler und die Dokumentierer/
 Übersetzer, die wichtigsten sind. Die Softwareentwickler stellen zwei
 Drittel, die Dokumentierer/ Übersetzer ca. ein Drittel und andere
 Tätigkeiten, wie z.B. Homepagepflege, Graphik-/Sounderstellung, nur
 ca. 5 %.
 Die wichtigsten Werkzeuge stellen die Mailinglisten für die
 Kommunikation und das Dateiablagesystem für die Produktion dar. Das
 Open Source-Projekt besteht einerseits aus wenigen wichtigen und
 zentralen Unterprojekten, andererseits aus vielen kleinen
 Ein-Personen-Subprojekten.
 
 Äußere Struktur bzw. Einbettung von KDE:
 Die Umwelt des Großprojekts besteht einerseits aus anderen Open
 Source-Projekten, Unternehmen und Endanwendern. Es gibt Konflikte
 zwischen der Umwelt des Großprojekts und dem Großprojekt
 selbst. Konflikte zwischen verschiedenen Open Source-Projekten sind
 selten, aber wenn sie auftreten, geht es um die normativen Grundlagen
 der allgemeinen Open Source-Community, wie dem konkreten Umgang mit
 den Lizenzen. Die guten Beziehungen zu anderen Open Source-Projekten
 werden durch die Nutzung von Werkzeugen dieser Projekte im Großprojekt
 untermauert. Weit mehr normative Konflikte um die Anwendung der Lizenz
 des Großprojekts gibt es zwischen dem Großprojekt und Unternehmen,
 wobei sich die Konfliktthemen um die Übernahme, Veränderung und
 Verkauf von Quellcode sowie um die Reputation durch copyright-Vermerke
 drehen.
 
 Funktionsweise:
 Eintritt:
 
 Aufmerksam auf das Projekt wurden viele durch die Nutzung einer
 Linux-Distribution, Freunde und Computer-Zeitschriftenartikel. Am
 Anfang des Projekts wurde aber vor allem über Mailinglisten und
 Usenet-Foren geworben. Das Projekt existiert seit 1996, die meisten
 sind aber erst 1999 bis 2002 eingetreten.
 Der Eintritt in die Community erfolgt nach dem Signalisieren von
 Interesse an der Mitarbeit durch Zusenden von kleinen
 Quellcodeveränderungen. Nach mehrmaligem Zusenden erhalten die
 Neulinge die Schreibberechtigung für das Dateiablagesystem. Dies
 erfolgt relativ schnell, im Rahmen von 0,5 bis 1 Jahr.
 Der Eintritt ist dabei als ein Selbstselektionsprozeß zu sehen, wobei
 die Selbstmotivation eine große Rolle spielt. Nach dem Eintritt
 besteht die Möglichkeit durch Reputation in den inneren Kreis
 aufzusteigen. Der innere Kreis ist eine schwer abgrenzbare Gruppe von
 Personen, die sich um das Projekt verdient gemacht und deswegen
 Reputation bzw. sozialen Status erlangt haben. Die Reputation besteht
 aus verschiedenen Elementen, wie Seniorität/ Erfahrung,
 kontinuierliche Leistung, freundlichem/kooperativen Umgang und
 Sichtbarkeit. Freiwillige Austritte erfolgen durch die Hinwendung zu
 anderen Aufgaben, wie Familie oder Erwerbsarbeit, Zwangsaustritte
 durch das Übertreten von wichtigen Normen, wie z.B. das
 unabgesprochene Löschen von Quellcode.
 
 Leistungserstellung, Arbeitsverteilung und Arbeitszusammenführung
 Es gibt eine operative und eine strategische Entscheidungsebene, wobei
 sich die operative um die konkrete Softwareerstellung und die
 strategische um rechtliche Probleme und visionäre Ziele dreht. Die
 strategische Ebene wird von den Personen aus dem inneren Kreis
 vertreten, die sich Reputation erworben haben.  Die Produkterstellung
 steht in dem Open Source-Projekt im Mittelpunkt. Die
 Softwareentwicklung erfolgt normalerweise in einem Versuch und
 Irrtums-Prozeß, wobei derjenige über seine Arbeit entscheidet, der die
 Arbeit macht. Dabei wird konkret entweder ohne anfängliche Skizzen
 bzw. andere formale Hilfsmittel sofort programmiert oder sich vorher
 im Kopf beim Sport ein möglicher Lösungsweg ausgedacht. Nur eine
 Minderheit entwirft vorher ein formales Modell, das später
 programmiert wird. Damit fällt die Leistungserstellung und die
 Arbeitsverteilung zusammen.
 Die Arbeitszeit ist sehr heterogen und stark gespreizt, zwischen ein
 paar Minuten und 14 Stunden pro Tag, d.h. ca. 0,5 und ca. 90 Stunden
 pro Woche. Im Mittel wird zwischen 2-3 Stunden pro Tag für das Projekt
 aufgewendet. Es wird vor allem während der Freizeit gearbeitet, wenn
 man von den Personen absieht, die für die Arbeit an dem Projekt von
 projektnahen Unternehmen, wie Distributoren, angestellt
 wurden. Probleme bestehen deswegen vor allem mit dem Partner und der
 Familie wegen des zeitaufwendigen Hobbys.
 Die meisten gaben an, bei 1 bis 4 Projekten mitzuarbeiten. Der Median
 lag dabei bei 2 Projekten. Die durchschnittliche Personenzahl sind 3-4
 Personen pro Subprojekt. Bei der maximalen Zahl liegt der Durchschnitt
 eher bei 6-8 Personen. Vereinzelt können Subprojekte mit über 10-20
 Personen auftreten. Die Personen aus dem inneren Kreis gaben an, bei
 Projekten mit mehr Personen als der durchschnittlich
 mitzuarbeiten. Außerdem sind die Personen aus dem inneren Kreis an
 mehr Subprojekten beteiligt als die anderen Projektbeteiligten.
 
 
 Die Arbeitsaufteilung erfolgt über die freiwillige Übernahme von
 Arbeiten, wobei ein Projektkoordinator mit Mitarbeitern sein Projekt
 überwacht. Bei der Arbeitsverteilung werden Absprachen zwischen den
 Subprojektmitarbeitern getroffen, wobei Vertrauen zur Einhaltung der
 Absprache eine wichtige Rolle bei dem Open Source-Projekt spielt. Der
 Projektkoordinator ist für die Fehlerlosigkeit seines Projekts
 verantwortlich. Vom Projektkoordinator wird z.T. die weitere
 Bearbeitung seines Projekts erwartet. Entscheidungen über die
 Übernahme von Quellcode oder die weitere Entwicklung des Projekts
 werden im Konsens gefällt. Allgemein ist die Zustimmung zu einer
 Mitsprachemöglichkeit im Subprojekt hoch. Doch gibt es eine Tendenz,
 daß Projektleiter und Personen aus dem inneren Kreis eine eher höhere
 Mitsprachemöglichkeit angeben als die Personen, die nur Beteiligt
 sind.
 Der Projektkoordinator hat dabei keine besonderen Machtbefugnisse. Nur
 Projektbeteiligte aus dem inneren Kreis genießen wegen ihrer hohen
 Reputation besonderen Einfluß und Vertrauen. Bei Konflikten wird von
 diesen eine Schlichtung erwartet.
 
 Die gemeinsame Arbeit wird in einem Release zusammengeführt. Es gibt
 eine offizielle Veröffentlichung, den Release, der nach einem
 koordinierenden Releaseplan herausgegeben wird. Zuständig für die
 Kontrolle dieses Plans und für die Übernahme von stabilen Programmen
 ist der Releasekoordinator, der diesen speziellen, koordinierenden
 Posten für den inneren Kreis übernimmt.
 
 Motivation/Gratifikation
 Es sind monetäre und nicht-monetäre Motivationsgründe zu
 unterscheiden. Die monetären Gründe existieren, da Personen für die
 Arbeit an dem Open Source-Projekt angestellt wurden (vergleichbar
 Sponsoring des Projekts). Andererseits bekommen die Projektbeteiligten
 Werbegeschenke und Geräte auf dem neuesten technologischen Stand
 ausgeliehen, was dem Sponsoring von Einzelpersonen gleichkommt. Einige
 gaben an, kurzzeitig monetäre Gratifikationen für bestimmte Arbeiten
 von projektnahen Firmen bekommen zu haben. Manche bekommen für
 Arbeiten um das Projekt, wie Vorträge und Zeitschriftenartikel Geld.
 
 Die nicht-monetären Motivationsgründe überwiegen aber in diesem
 Projekt. Die Motivation der Projektbeteiligten setzt sich aus einer
 Mischung intrinsischer und extrinsischer Elemente
 zusammen. Intrinsische Motivationen sind eigene Probleme zu lösen oder
 der Spaß am Programmieren. Diese Motivationsgründe wurden von einer
 großen Mehrheit als wichtig bezeichnet. Die extrinsische Motivation
 ist u.a. auf die Community und ihrer kooperativen Kultur bezogen. Dazu
 zählen soziale Anerkennung (Reputation) und gegenseitige Hilfe. Diese
 Motivationsgründe werden auch von einer Mehrheit für wichtig
 erachtet. Konflikte können dabei einerseits die Motivation im Projekt
 durch Beleidigungen senken, aber andererseits durch das wecken von
 Ehrgeiz erhöhen. Die zukünftigen Arbeitsplatzmöglichkeiten stellen
 auch einen Motivationsgrund dar.
 
 Die persönlichen Treffen stellen eine wichtige Motivationsquelle
 dar. Die Personen, die schon länger am Projekt beteiligt sind (innerer
 Kreis), haben schon andere Projektbeteiligte getroffen. Die Treffen
 erfolgen vor allem auf Linux-Konferenzen, seltener auf
 projektbezogenen Programmiertreffen, wie vor großen Releases, oder
 wegen räumlicher Nähe.
 
 Mit der Motivation hängen auch die Hobbies zusammen, da das Projekt
 als zeitaufwendiges Hobby angesehen wird. Es gibt eine Fraktion die
 generell technikfasziniert ist. Es können zwei Lager ausgemacht
 werden: das erste verwendet das Programmieren zum Abschalten und das
 zweite , bei dem die Personen keinen Computer mehr sehen können. Sonst
 fällt nur auf, daß die Hobbys stark gestreut sind. Das Lesen von
 Comics, Science-Fiction- oder Fantasybücher ist und sportliche Hobbys
 sind verbreitet.
 
 
 Kontrolle
 Die Kontrolle der Arbeit im Open Source-Projekt läuft über die
 Kontrolle der Qualität des Quellcodes. Dies erfolgt auf der operativen
 Ebene. Die Qualität wird durch Selbstkontrolle durch gleichzeitige
 Nutzung der Software, stichprobenartigen Kontrollen durch
 Projektkoordinatoren und den Einbezug der Endnutzer über ein
 Fehlerberichtsystem erhöht. Es besteht dabei ein Konflikt zwischen der
 selbstbestimmten Arbeitsweise und der Endnutzerorientierung der
 Community, was sich in kleineren Streitigkeiten entlädt. Auf der
 strategischen Ebene kontrolliert der innere Kreis die Einhaltung von
 Normen bei der Produktion, Kommunikation und Nutzung der gemeinsamen
 Software. Dabei ist der innere Kreis für die Einheit des Großprojekts
 bzw. für das einheitliche Auftreten zuständig.
 
 Es kristallisieren sich drei Kanäle für Störquellen heraus. Erstens
 gibt es Konflikte bei der Kommunikation, d.h. auf den Mailinglisten,
 aber auch beim Chatsystem. Hier sind die meisten Störungen zu
 finden. Störungen von Projektbeteiligten werden verbal geahndet,
 projekt-externe Störungen werden üblicherweise ignoriert. Zweitens
 gibt es bei der Nutzung von Quellcode hin und wieder Konflikte und
 Probleme mit Trittbrettfahrern, die sich um die GPL-Lizenz
 drehen. Dies wird normalerweise bei Firmen durch schlechte Publicity
 geahndet. Drittens kommen Störungen bei der Leistungserstellung im
 Dateiablagesystem selten vor. Dies wird durch Zurückspielen des
 vorherigen Quellcodes und u.U. Sperrung des Zugangs sanktioniert.
 
 Es gibt bei den kommunikativen Konflikten mehrere Themenbereiche, die
 öfters auftreten. Der erste Bereich, der am häufigsten Auftritt, ist
 über Konflikte bei der zukünftigen Entwicklung des Großprojekts und
 der Subprojekte. Im zweiten Bereich, der seltener auftritt, kommen
 folgende Konfliktgründe vor: Nichtbeachtung von Beiträgen, Ablehnung
 von eingereichtem Quellcode (z.B.: patches), Löschen oder Verändern
 von Quellcode, Qualität von programmiertem
 Code/Übersetzung/Dokumentation und Art der Kommunikation. Ganz selten
 bis nie treten die Konfliktarten Aufgabenverteilung, (verkannte)
 Anerkennung für geschriebenen Quellcode, Selbstüberschätzung der
 eigenen Leistung und Anspruchshaltung auf.
 
 

 Abstract:                                              
 
 For almost as long as Unix has existed the shell script has been a integral 
 part of the system.  These shell scripts automate and control the system and 
 allow users to encode complex tasks into a simple program.  Over the course 
 of evolution of the Unix Desktop the GUI (Graphical User Interface) has made 
 scripting Unix applications much more difficult.  One solution to this 
 problem in the KDE (K Desktop Environment)1 project was to use DCOP (Desktop 
 Communications Object Protocol)2.  DCOP allows developers to export 
 functionality of their application to be controlled from external 
 applications.   This can allow users to automate GUI applications without the 
 need of mouse event recording and custom event recorders.   
 
 The two main focuses of this paper will consist of the development of useful 
 scripting interfaces for automation and the use of them from the system shell 
 and python.  The first portion will deal with using proxy classes in KDE 
 Libraries to export complex functionality from widgets to the outside world.  
 It will also deal with issues of how to effectively provide interfaces for 
 scripters to use.  The second portion will cover how to effectively use dcop 
 interfaces from shell and python.  It will also discuss the use of 
 KScriptInterface3 script engines to provide macro facilities to applications.  
 
 1) More information can be found at http://www.kde.org
 2) DCOP Information can be found at 
 http://developer.kde.org/documentation/library/kdeqt/dcop.html
 3) KScriptInterface Developer information can be found at 
 http://developer.kde.org/documentation/library/3.1-api/classref/interfaces/KScriptInterface.html

 I know the deadline has passed already. But you might want to consider this 
 anyway. If of interest, I can hold a talk about TaskJuggler. A Qt based 
 Project Management tool we have developed at SuSE.
 
 Abstract:
 <--8<-->
 
 The talk is an introduction to the TaskJuggler Project Management Software. It 
 will describe the concept and ideas behind TaskJuggler and then continue with 
 a brief overview of the project description language. Basic topics like task 
 hierachies, resource definitions, resource allocations, vactions, and shifts 
 will be covered. 
 
 Using a made-up software development project as an example, the whole workflow 
 of project planing, project tracking and profit and loss analysis will 
 illustrated. Finally report generation and XML exporting will be explained. 
 
 The talk is intended for everybody that is involved with planing and tracking 
 of projects. More info can be found at http://www.taskjuggler.org.
 <--8<-->
 

 Abstract
 
 As technologies like distcc (http://distcc.samba.org)
 and teambuilder (httpp://www.trolltech.com/products/teambuilder)
 came up, it became clear that automake hinders us
 in getting the best ouf ot these tools. The other problem
 with automake we have is the need for am_edit to get
 our developers to code instead of fiddling with Makefiles.
 
 My talk will _shortly_ introduce the way our build system
 is set up and then I'll go on giving you an idea why unsermake
 is such a great replacement for automake and why do you 
 want to use it even on single machines.
 

 Abstract
 
 KDE's rich and continously growing set of applications as well as its=20
 exemplary
 stability and performance offer the chance for traditional Windows users in
 administrative and business environments to migrate to Linux not only in the
 server but especially also in the desktop area. At the moment we face the
 beginning of such a transition process and there are already a number of
 promising examples for it.
 
 However, this situation raises the demand for an in depth comparison of
 usability concepts between KDE and traditional Windows desktops. Our paper
 describes our activities and results from a task-based study, which tried to
 gain new insights in this domain and was carried out in June 2003.  It
 discusses the intentions of a test with a significant number of ``tradition=
 al
 Windows users'' who got the chance to solve a number of standard office tas=
 ks
 on a KDE system as well as on a Windows XP system. The users behavior was
 filmed and analyzed afterwards.
 
 We show the way we have configured the KDE desktop to meet the expected=20
 demands
 in a proper way, explain our intentions and rationales and evaluate the=20
 results
 of this study. The paper raises a number of questions that we consider worth
 observing for future development and indicates the great challenges but
 especially opportunities that result from the migration of large installati=
 ons
 from Windows to Linux systems in business environments.  A general trend in
 this direction can be expected for the near future.

 Abstract
 
 GStreamer is a full-featured media framework, currently included in the
 stable Gnome-2.2 desktop series. KStreamer is the nickname for the
 KDE/QT bindings for GStreamer, currently used in KDE-applications like
 JuK. This paper will aim to give a demo/overview of several things that
 are possible with this powerful framework, how GStreamer is technically
 built up, and how KStreamer could become the basis of a new media
 framework in KDE-4.0.