gbgsoft and the Open Source Model

Over the span of 15 years, gbgsoft has replaced its dependence on proprietary software where ever possible. We use Libre Office, not Microsoft Office; Thunderbird, not Outlook; and Firefox, not IE. The tool kits we use to make programs are all open-source under various licenses. Most open-source these days is platform agnostic. It will run under Windows, Mac, Linux. In fact we choose our tools precisely because they will work in all three platforms.


“If I have seen a little further it is by standing on the shoulders of giants.”

-Sir Isaac Newton in a letter to Robert Hooke (Feb 5, 1676)


“Today, Newton would probably get sued for patent infringement.”

-Rick Gregory, Senior Programmer gbgsoft (Jul 15, 2006)

Why Open-Source?

For one thing it’s cheaper. That’s not to say that it’s devoid of cost. All projects encourage financial contributions and we make it a practice to support our key suppliers through regular donations. Each software project also has a community of supporters and consultants who provide support on a per hour basis. This means that high quality support is always available. And it is often these support dollars that pay for the primary development of the next generation of the software.

Each generation of open-source software follows a steady development and release plan,  publicly arrived at and adhered to. This is good news for the software’s users. Most people don’t have the time or inclination to know what the next versions are going to look like, and arbitrary changes by software producers have become the bane of most corporate IT departments. There have been upgrades of MS SQL versions that have brought entire enterprises to a screeching halt while the compatibility issues get sorted out. We work with PostgreSQL, the open-source database, and have undergone 3 major releases without incident.

Open-source software is higher quality. While proprietary software may gain a temporary advantage by having the “hot new” feature, it has a poor record in terms of security, preservation of privacy, and the fixing of known bugs. In the open-source world there is an overall transparency and visibility in code that proprietary companies lack. As the aphorism goes, “given enough eyeballs, all bugs are shallow.” A phrase the open-source community has wholeheartedly adopted.

Open-source is trustworthy. We now know that Microsoft delayed fixing bugs and broke its own encryption schemes, all in the service of making it easier for the government to spy on its citizens. Not only would no open-source project ever do this, but given that the software’s code is out there for all to inspect, any such activity would be exposed in an instant. It turns out that transparency is our best guarantee of privacy. A US Supreme Court judge famously wrote “Sunlight is the best disinfectant.”

Open-source gives you choice. Can you name two closed-source Office Suites? Most people can’t. In the open-source world there’s Libre Office, Open Office, KOffice and Calligra Office, to name a few. Most of these are multi-platformed. Closed-source likes to dominate the market, saturating it with a single product,  limiting your choice, and stopping you from getting the tools you really need.

In the end, open-source encompasses a different algorithm for paying smart people to create interesting software that users actually need. This pushes forward innovation, reliability and quality for both the programmer and the user. IBM, the world’s oldest and perhaps most respected computer company, supports several open-source projects with commitments running to the tens of millions of dollars annually. They see these open-source projects as intimately tied up with and integral to their own success. Projects large and small are all being supported by individuals, organizations and companies whose economic interests have aligned in often synergistic ways with the open-source community. And unlike the closed-sourced world where marketing and distribution issues dominate the agenda, all this open-source money goes directly to the funding of developers and development.

Open-source means better software.

Written by: Rick Gregory and Andrew Gregory

Read More

Our Process

We’ve had a lot of experience with different application needs and program eco-systems. Over that time, we’ve worked out a pretty fool proof way of doing our work. The software industry has a long history of creating the methodology ‘du jour’ and then giving it a fancy marketable moniker.  Notable are Agile, Xtreme, UML, the Grady Booth method, and  the Yourdon methodology.

We couldn’t think of a catchy name, but there are several precepts we do follow.

1. Close to the Client

Our average system remains in use for over a decade and several are in the middle of their third decade. The reason for this is that we we go to great lengths understand what our clients need their software to do.  This involves extensive interviews with clients about their needs and critical objectives. This is a very empathetic process. Good software anticipates and shapes work flow and information in ways that leverage clients’ key capabilities. When it’s done right the whole process smoothly glides the program into being and we end up forging an enduring long-term relationship with clients.

2. Business Logic should be encapsulated in data structures.

Programs should administer data structures. This is sometimes difficult to fathom, but let’s look at a simple example. Let’s say that we want to email birthday greetings so many days before a person’s birthday. You could write the program to send birthday greetings  three days prior. But it would be better to create a database into which the client can store a ‘Birthday greeting interval’ that would then get applied automatically as the calendar advances. If usage shows that four days is a better interval, that decision can be implemented without changing the program.

3. Data Validation.

A corollary of Precept #2 is that data should be validated. If you are adding a new record to your master data table (a customer, a contact, a client or a member), there is certain information that must be properly entered in order for a record to be considered valid and usable. Some fields must not be empty. Some fields should only be validated against a list of pre-defined alternatives in order to ensure data quality. (An example is picking a province from a drop-down box of choices.) Program logic and data structures are externalized into control table. These are then manipulated by the program, using the data created and maintained by the client to administer very complex business flows.

4. Deliver early, deliver often.

This is known in the trade as  RAD (Rapid Application Development).  It entails creating many iterative releases from which the final program ultimately emerges. We’re firm believers  in this.  It involves the client in the details of the system; giving end users real input and control over the way the system ends up working. It not only results in a better system but one which receives a broader and deeper acceptance of the program by users. Secondly, RAD catches bugs and gets them fixed earlier. There is a famous software aphorism that says that given enough eye balls, all bugs are shallow. This has certainly been true in our experience. Finally it prevents poorly implemented features from disrupting workflow as they become the norm. Programmers, being human, get enamoured of their own thinking and can easily program themselves into corners. Frequent iterative releases tests these ideas early on and they get refined or dropped. Either way, we don’t end up spending time and money on stuff that doesn’t work.

5. Do the reports last.

Often the design process becomes dominated by a list of reports, existing or otherwise. It’s easy to think in terms of reports, but using these as a starting point is usually a mistake. A report is a static time-frozen representation of data. Having a new system usually means that data and work flows are going to change. Premature consideration of reports closes important areas of exploration. For a program to succeed it must creatively manage those work flows; creating the data on which to report. In additon, writing reports requires a reasonable amount of data to use as the raw material of the report. The RAD process usually generates a fair bit of testing data for use when report creation time comes. Lastly, until quite late in the process of development, data structures and the like are highly volatile, changing in response to testing and refined program design. Unless left until quite close to the end, you end up writing the reports twice, a not very efficient use of client resources. We feel so strongly about the importance of getting the reports right that we have an entire separate page devoted to the topic.

6. You get the source.

When we write a system for clients, they not only get the compiled binary program, they also get all of the source code created for the client, our development library itself (released under the GPL) and a working copy of the development IDE installed on one of thier servers.   This leaves control exactly where it should be, in the hands of the client. While we  like clients to continue using our development services, they are not required to do so. Clients have everything they need to change and build new versions of the program. This arrangement is part of the fundamental relationship of trust that we strive for.

Written By: Rick Gregory

Image Sources:
http://www.aust.edu.ng/school/index/computer-science/about
http://www.edrawsoft.com/Yourdon-and-Coad.php
http://photo.elsoar.com/many-people-playing-video-games-pictures.html

Read More