Why Open Source

Source: Dev.to

Introduction

This document explains how I came to write an open‑source software project.
The reasons are numerous and interesting. It is a non‑technical document about my history.

In short, the main reason for creating an open‑source project was that I benefited from using other open‑source projects. I understood their value and decided to make my project open source as well.

The decision to start my own framework stemmed from the fact that companies can drop their products—or their product life‑cycles may end at a given time. I often find it hard to keep pace with such life‑cycles, so I prefer to stick to an older product for a longer period.

I will extend this document from time to time and fill it with more of my history (in the GitHub Pages version).

Lothar Behrens – Saturday, 20 Oct 2024

After reading to the end – would you like an MFC code template?

At the end of this article I conclude that I will create an MFC application again. The main reason is explained there.
The starter for that would most probably be a template that generates code based on the MFC framework. My main question is: Would you like to have it?

Early Days in Computing

My first computer was one I bought at the start of my education. It was an IBM‑PC‑compatible machine with only 512 KB of RAM—enough for the time. It ran MS‑DOS and GEM.

During my studies I grabbed every book I could find and read through them, learning the ins and outs of computers.

I learned programming with BASIC (on my aunt’s C64). Very early in my education I realized there were better languages than BASIC, so I never did anything with my Schneider PC’s BASIC 2 (Locomotive Software).

Starting with Programming

As mentioned, I purchased my first computer shortly before (or at the beginning of) my education, and I quickly stumbled upon an object‑oriented language. It appealed to me more than BASIC, so I made my next purchase accordingly.

In school BASIC was the language we learned, and I was often ready before the rest of the class—probably because I had already used BASIC on the C64, which is similar to GW‑BASIC.

My First Software Ideas

When I got Turbo Pascal, I also got my first ideas for a software project. During my studies I collected many floppy disks, and it became cumbersome to keep notes on paper or on stickers to remember what each disk contained.

I wrote dateiver – a disk‑cataloguing system with a command‑line UI. Even today there are many command‑line tools on Linux that work together and are very helpful, but my application was a standalone program not designed to interoperate with other tools.

Note: The folder name was different back then. I didn’t structure my source code well, which later caused struggles. dateiver was later copied over for a new application called Tvvt.

At that time I also learned a lot about programming data structures, which I needed for the disk‑catalogue. Databases were unknown to me then, so I focused on data structures, file I/O, and traversing the file system to read data from a disk.

A First Attempt for a Customer

After finishing my studies, a potential customer contacted me asking if I could implement a specific feature. I negotiated the requirements and delivered a first solution.

Unfortunately, the customer was not satisfied. The UI was still console‑based, which looked unappealing to them. I was a beginner and had failed to meet expectations.

The Professionals Use SAA

Later, when I tried to market dateiver as a shareware version, I was told the application would not sell because it lacked a modern UI. The software dealer I approached was not interested in offering it in his store.

I learned that many customers (not just this one) prefer a graphical UI over a console UI. The shareware seller suggested I look at the fancy SAA UI toolkit, so I did.

To use SAA, I had to buy a newer compiler and migrate my code from Turbo Pascal 5.5 to Turbo Pascal 6.0.

My First Model‑Driven Ideas

After learning SAA and modern UI concepts, I discovered a dialog designer in a book. It promised to help with software creation. I quickly realized I could do more with it and created my first model‑driven application development environment, TVBuild.

After Pascal Came Windows and C++

Time passed, and I needed a more modern computer. After my Schneider PC, my next purchase was a sub‑notebook (one of the first DIN A5‑format notebooks) – still a MS‑DOS‑only machine.

I then bought a tower 386 DX 40 PC with Windows 3.1 and a whopping 4 MB of RAM. With that machine I also purchased one of the fastest compilers of the era, Watcom 10.6, famously used to compile Doom.

Using Watcom, I learned C++ and Windows programming. I started with the simple C API, quickly moved to object‑oriented programming, and began using MFC.

At that point I still hadn’t done database programming, so I repeated my earlier experiences with data structures—this time within MFC. I used DrawCLI as a base for an application I wrote for a model‑railroad club that also operated real steam locomotives and historic trains.

Trainres and the Journey Through MFC

With the new compiler and some help from club teammates I wrote a train‑reservation system – or at least I tried to. A stakeholder wanted fancy diagrams of the ride, similar to the maps shown in train stations, but in a shrunken‑down version. This was back in the era of 16‑bit Windows 3.1 on my 386 DX 40 MHz machine.

At that time I pushed my knowledge as far as I could. I was eager to develop the application further for the club.

The screenshot (described) shows a net list with red‑colored lines representing two train‑ride plans. The application reacted to entering a plan by drawing the respective tables, allowing the user to add ride‑time schedules below the header.

The plan was also to use that graphical presentation to store data. A customer was entered into the bottom‑left window and registered for train ride 001. All of this was built with data structures and the basics of DrawCLI.

Trainres – the MFC Version Survived Into Windows 10

Later the application survived into the Windows 10 era and can now be developed with Visual Studio.

Starting to Learn Databases

After a while using Watcom 10.6 and MFC, I noticed a much fancier development tool: Power++ from Powersoft. Powersoft had purchased Watcom’s compiler tools and database components, which I wasn’t aware of yet.

The marketing of Power++ appealed to me because it promised rapid‑application development (RAD) and included a built‑in database, allowing me to learn databases quickly.

I Began Porting Trainres

When I purchased Power++ Developer (the smallest version available at the time), I started porting my club application to use the Power++ class library. While doing this I spent more time building sophisticated diagramming features than the database itself. In hindsight, I neglected one of the biggest issues in my career as a professional software developer – I still wasn’t professional.

The diagramming capabilities were interesting because I had written my own interpreter to let users design their own symbols. The data was stored in a database, and I even had simple customer entries in a table.

Sybase Dropped Power++

Eventually Sybase decided to drop Power++. I was upset – not only had I wasted money, but my porting effort seemed like a dead‑end. I stopped development immediately because it no longer made sense. The club never received a running application.

I learned the hard way that companies don’t always care about their smaller customers. I never found out why Power++ was dropped; there was a final release I missed. Years later I discovered that Sybase gave the Enterprise version to all registered customers, even those who owned only the Developer version. I later returned to the Enterprise version.

At that point I had to rethink my development approach. Around the same time I started learning Linux – the new thing. I wanted to program on Linux as well, so I explored APIs and frameworks and settled on wxWidgets because it was free and would save me time.

While experimenting with Linux and Windows in parallel, I realized I wanted to run the application on one machine and use the other as a server, communicating together. Client‑server programming became the next big challenge, building on my earlier database work.

It was 1999. Long story short – I started a new project that I still work on today…

The Birth of My Open‑Source Project

My new project was not yet open source. I tried to create a UI wrapper that would not depend on any specific UI framework. I wanted something akin to CORBA, but built by myself, because I had lost trust in commercial products that forced me into rewrites whenever the vendor changed.

At that time I had a job as a software developer, gaining experience in client‑server and database programming. I also learned CVS, a version‑control system. Jumping into the deep end gave me valuable experience that would pay off later. I transitioned from hobbyist to professional software developer – still a beginner, but that’s another story.

Starting My Open‑Source Project

After making progress with my Windows and Linux experiments and the first attempt at my big project, I stepped back and reconsidered the goals. The scope was too large to tackle all at once, and I realized the initial attempt would not succeed at the scale I imagined.

Nevertheless, I continued with a full rewrite. Most parts were reusable; I only needed to make them compatible with the new design. The code snippets are still viewable in the CVS project history.

Now I have migrated the repository to Git, preserving the history. This Git migration is part of my current effort to restart development after a long break. I ran into another show‑stopper – CVS – but that is a story for another time.

Why I Started an Open Source Project

Products often provide their own frameworks. Those frameworks may be available with other products, but there is no guarantee that no porting effort will be required.

If a product has no common framework—such as MFC (used in Watcom and Microsoft Visual C++ onward)—you end up using its proprietary framework and risk being locked into that product line. It wasn’t just a lock‑in (Power++); it became a show‑stopper when Sybase decided to drop that product.

With my own framework I can do the same thing those companies do, but under my control. I can keep using it, make decisions at my own pace, and still make it publicly available. The project has been started, rewritten, made public, and remains in active development in a stable state. I designed it similarly to COM or CORBA, using pure abstract classes (i.e., interfaces). That design choice is the main reason the project is still alive.

Current State and Why It Is Still Alive

Today the project is alive for two main reasons:

1. Modular Design – Early on I rewrote the initial design into a fully modular software system. I understood what COM demonstrated: its interface‑design technique. COM’s interfaces are defined once and never change; if a change is needed, a new interface (often with a version suffix) is created. I adopted a similar approach using C++ pure abstract classes, rather than a low‑level C‑style binding technique.

2. Personal Stakeholder – I am the primary user of the framework. It provides cross‑platform capability (macOS, Linux, Windows) and a model‑driven software‑prototyping approach that lets me quickly develop database‑software prototypes. This capability was missing in the earlier Power++ migration, which left the product unfinished.

Now I can generate a modern‑looking application from a UML model (the main application itself) in a completely different language and framework.

Why Has MFC Survived So Far?

MFC was the main UI toolkit in the past, and Microsoft used it in its flagship products—the “cash cows.” A huge amount of investment has been made in those projects, so Microsoft has stuck with the technology.

• Large legacy codebases make it unlikely that Microsoft will drop MFC in the near term.
• Developers often stay on an older Visual Studio version to avoid breaking existing MFC projects.
• Microsoft continues to rely on a vendor that provides UI improvements for MFC. If that vendor encounters trouble, Microsoft could acquire it, which would further cement MFC’s future.
• Features such as the Ribbon UI are still being developed with MFC, and Office itself likely uses the framework.

Why Do I Mention This?

My open‑source framework (or rather, the main application built on it) looks a bit outdated on Windows machines. I plan to give it a fresh look—only on Windows—by creating a commercial spin‑off.

Why Do I Use MFC Again?

The modern GUI features that MFC now provides are key for contemporary applications. I also want to support prototyping of MFC‑based applications.

Is There a Commercial GUI Library Backdrop?

Yes. However, my framework is designed to avoid lock‑in. By keeping the architecture modular, I can:

• Integrate commercial libraries such as DevExpress when needed.
• Reuse as much of my existing C++ code as possible.

The modular design gives me the flexibility to choose the best UI toolkit without being tied to a single vendor.

Conclusion

That’s the story of why I started open‑source development, a brief outlook on the project’s future, and my current activities. Feel free to explore the code:

• lbdmf repository – kept as close as possible to my development workflow (currently migrating to Git).
• Other repositories – snapshots of past work, not well‑structured, shared for fun.

Thank you for reading!