It's been 10 years since I joined Kexi and thus the KDE community. I think writing down some history and summary makes sense.
2003-03-28: first touch on Kexi sources for porting
It all started at a technology fair in Warsaw, 2003. I wasn't too keen to go but got free tickets and free time. I met a founder of OpenOffice Polska LLC (later renamed to OpenOffice Software) from Warsaw presenting its adaptation of deeply localized, nicely prebuilt office suite based on OpenOffice.org. The office suite has been open sourced StartOffice over two years before by SUN and then localizations or user handbooks basically did not exist. During the meeting among other topics we also discussed apparent missing bit in the OpenOffice.org suite: a rival of MS Access. I proposed to perform some research on how the app can be added. I got hired and engaged full-time from March 2003.
The business model was largely similar to what is known from server Linux tools or support subscriptions: offer the tools for free, with the source code, and build products and services (such as support) on top. I was already confident that my adventures with open source would start soon, I just wasn't sure what project to join.
My initial attempt should have been obvious: say hello to OpenOffice.org to start a MS Access clone project within it. That was nice theory but has never worked since OpenOffice.org project wasn't even semi-openly governed. Talking to OO.org meant talking to SUN Microsystems. A small company is rarely a part in such relations.
So another solution was to start from scratch or join existing open source project that shares our goals.
By that time a great smart guy Lucijan Busch from Austria already started his work on Kexi which he launched as a summer project in 2002. (a hint for all of you who think you're too young to start doing some KDE Junior Job, you are wrong, Lucijan was only 16 years old when he started Kexi!)
Based on the business model of OpenOffice Polska, Kexi had to run natively on Windows to integrate well with to OS. So a side effect of my project was the KDE on Windows initiative that resulted in another general-purpose target for KDE software which is now a subproject on its own. Initial selection of features (such as larger parts of KDElibs) was closely related to needs of Kexi Windows port. I owe a big credit to my employer that it allowed me to contribute in a sane way instead of just accepting code forks.
Naturally, for some time I was the only hacker using MSVC for actual KDE code. Having the Linux KDE Desktop around all the time but about first three years of my Kexi development was happening in a MSVC IDE. The primary reason for that at the time was poor availability of debugging tools for Linux and slow gcc compiler. And Kexi was already a really complex layered app for me, developed with limited head count and time pressure. On arrival of powerful hardware, Qt Creator and KDevelop tools that reasoning more or less disappeared. Even though I still see certain teams working this way, this is no longer happening in the Kexi project.
The investment resulted in Windows version of Kexi dynamically linked with commercial Qt as GPL version was not available for Windows back then. The software at the KDE side was fully LGPL, so that option was all legal. Just like it was the case with our OpenOffice offerings, our Kexi customers were coming from Windows. To make everybody’s live easier I prepared combined installer offering the OpenOffice apps and Kexi bundled side-by-side on a single CD.
Another nice credit for my employer could be that there were no unpleasant "code drops" once a year of so. Full code of Kexi always immediately landed in the KDE repository what was a result of development happening directly within the KDE infrastructure. And for direct benefit of KDE users on Linux the Kexi code had Linux/Windows multiplatform nature inspired by Qt itself, with Mac versions available too. After leaving OpenOffice Software LLC, I am following this track for any development within Kexi even while its LGPL would permit different strategies.
As a result Kexi was relatively popular on Windows among people using the company's OpenOffice flavour and especially outside of Poland (both English and Polish localizations were supported). By "relatively" I mean Kexi is more specialized tool than a general purpose office apps such as a word processor. And as expected not many paying customers were interested in non-Windows versions.
Summing up, given the amount of freedom, the employment at OpenOffice Software felt a bit more like a sponsorship. It lasted until late 2008 and my full-time development of Kexi lasted until late 2007.
In summer 2004 Lucijan left the Kexi project and I took over the maintainership.
After six months or so I realized I have some thoughts to share with my new KDE friends. To give back to those from whom I am learning new things. Now I see a majority of my 132 blog entries were devoted to Kexi, KOffice/Calligra or KDE on Windows. (By the way. I'd like to encourage those of you that are "just coding" to start blogging too. It's not necessary to be a fan of philosophy, sociology or psychology like Aaron :) But at least I can see many of my contributions that were inspired by one or another blog or talk. Or just a comment. So maybe this process is recursive? When you work remotely why wouldn't you let others to better understand your dificulties, reasons for certain decisions or conversely? It will never hurt)
Coding is only a part of the story. During the time like many others I gave a few presentations on Kexi at conferences or meetings devoted to education or open source, including KDE Akademy. Kexi was topic at numerous KOffice/Calligra developer meetings. During the development thousands lines of IRC discussion have been exchanged, dozens of design documents (wikis) created and tutorial written as well as two handbooks. I exchanged hundreds of emails with contributors and users. Recently we started to advertise to use the dedicated forum. Managed to push many releases. It is always interesting to realize how diverse are needs of Kexi users. Supporting wide spectrum of use case can give extra satisfaction.
While I've been working on Kexi for two years or more already, I noticed SUN finally started its OpenOffice.org Base project, truly the only OO.org app that wasn't migrated from the StarOffice suite. I quickly noticed that the SUN's Java and servers mindset left its stamp on Base. Being based on a Java database back-end it was more resource-hungry for available desktop computers that were available at the time. Secondly, Base was also internally more based on Writer than an independent app. It apparently followed the habit of OpenOffice to mimick the MS Office's look and feel. It was clearly a huge and risky effort for a new app. Thirdly, Base's the local storage was based on compressed XML (to me another sign of SUN's Java and servers mindset), which is useful for documents, systems integration and standards such as ODF but which is also a nonsense for anyone accustomed with physics of relational databases (including MS Access' Jet back-end). After realizing this I was rather happy I had no opportunity to join the project. My employer shared this opinion.
The Kexi project operates in specialized area within a hard market filled with proprietary "enterprise" solutions. In the meantime while Kexi was evolving a number of respected and already powerful open source competitors passed away. Rekall was open-sourced in 2003 but faded when the company behind it disappeared already in KDE 3 times. The same applies to Knoda. As of now Glom database tool for GNOME is actively maintained. And while OpenOffice/LibreOffice Base is of course maintained, these do not seem to be as actively developed as other apps from the respective office suites.
That said, primary competitors such as Filemaker or Microsoft Access are big and enjoying diversified funding. They are apparently trying to secure their market share by using closed document formats, something especially important for this data-oriented software. Despite of all its "interoperability buzz" around the proprietary DOC, XLS and PPT formats MS never agreed to open up its MDB format. This way programs and databases based on MDB remain the most closed ones; realistically you cannot switch a compiler or database engine.
Through its history a number of talented developers joined the Kexi project and contributed with their valuable time. Two of them shared especially long time, Sebastian Sauer and Adam Pigg. Adam is still the contributor to Kexi and Sebastian is active in Calligra too. Of course one big contributor is also the Calligra and wider KDE community as a whole because Kexi shares the common development infrastructure and various initiatives.
In 2012 new developers joined and are already contributing. There is also pretty much high interest in Google Summer of Code tasks related to Kexi even while at most one slot is available every year.
The question of developer workforce needed to generate a snowball effect appears constantly. Rational users know that most complicated improvements would need sponsored developers and coordinated effort. Perhaps dedicated Kexi Foundation accepting donations worldwide would be the answer? That would be similar to what the sister Calligra's project Krita just did last year.
10 years. So yes, I am that old. A software architect who still remembers how to program and actually still programs. All that wouldn't be possible without supportive people that one can meet on the way. And never to forget, special thanks should go to my lovely wife and the whole family.
For curious here is a visual time line presenting large part of computing history. History of Kexi and KOffice, Calligra and KDE has been combined into a single graph completed with a bit of historical context, even with competing OO.org and MS Office projects. From the "Lines of code" column (counted using the SLOCCount tool) you can note that size of the code base of Kexi did not increase too much after 2009. This means the activity leans towards removing defects from the app and improving its usability and existing features rather than developing new ones. This makes difference for the users given the available resources are limited. Even while users are hungry of new cool features only a few simpler features have been added during this period.