At work lately I’ve been encountering a lot of Business Process Management or BPM tools in disguise. It got me to wondering if the open source community is active in this area. I found this blog post which suggests maybe. These do appear to be mostly free, but they have commercial companies around them which always complicates the issue.

Today my colleague pointed out a commercial RAD tool that was very promising. It’s called outsystems Agility Platform and it is worth a look if you are in the market for this kind of solution.

What does all this mean? Nothing maybe. Eventually it could spell the end to the software engineering profession as it exists today. I doubt that will be tomorrow, but it could happen. Wouldn’t that make for an interesting world?

It is the plight of the modern software engineer to know that there is always more than one way to solve a problem. Often we struggle with trade offs between usability (our own) and performance (the users). Eventually we individually or collectively chose “something” only to find that a single choice then cascades through our entire solution. If you don’t believe me you can validate this for yourself. Just ask a software engineer their “best practices” for managing dates and date logic and watch their eyes roll.

For my part, I’m just as bad as the rest. I chose scripting over compiled for the instant gratification. I chose free over commercial because I’m cheap! I chose frameworks for their lightness, ease of use and ability to get out of my way when I need them to. I chose operating systems for their ease of use rather than cost because I have no passion for fighting obscure OS’s.

It is in the midst of making all these “choices” that I’ve come to realize why modern software is the way it is. Choices, made by developers with the best of intentions, will drive the evolution of a product deep from it’s very core architecture on through to the user experience it eventually will present. This is not universally true, but in commercial offerings from all but “the biggest” providers this is often easy to spot. The question is, do we care. The answer is, we better if we hope to evolve past this point.

As I thumb through my copy of Algorithms in C++ I’m reminded that although ease of use is arguably more of a subjective measure, performance at the very high end of the spectrum is materially impacted by built to purpose. As a for instance, take the Relational Database Management System (RDBMS). The spread of these solutions has been matched in equal measure by the explosion of built to purpose (domain specific) applications that dot the software landscape today. This was all well and good, until the recent growth in high performance, high availability and high user count solutions that the web community now demands. Software engineers have quickly begun to look beyond the venerable old work horse that is the RDBMS towards distributed document based database management systems or the cloud as some prefer to call it.

The problem is, document DB’s are good for some solutions, but they are not ideal for everything. Yet recently I’ve seen people assert that all DB’s should be document based. It is here that the trouble starts. Human nature is to find the “best” way to solve a problem and then always solve it that way. Software, really good software, is about finding the best way to solve a very specific problem, but also about having the intellectual awareness to recognize that other problems which may look “very similar” are in fact different enough in their need to warrant a different approach. The challenge becomes how to create tools such as frameworks or even open or closed platforms that will help us scale and adapt our solutions organically without changing code in every part of the application. This is no small task.

This is the holy grail of the passionate software engineer. To build a solution that is usable and scalable without becoming brittle. As we look in our tool box we are convinced that we have enough of the basic building blocks to achieve this result. We try and try again. We spawn new projects, frameworks, patterns, approaches, and slowly, painfully, we move the ball forward. We are not there yet, but I think that big gains are coming. To that end I will keep making choices. I will chose each building block I need through the filters and lenses that work for me. I will keep my mind open and objective. I will do “just enough” to achieve what is needed for my solution, but I will also carefully review every choice to determine what it’s implications are for tomorrow. Performance and flexibility will continue to color my perception of each new tool. I encourage every passionate software engineer to do the same!

If you are an open source developer and you have not been living under a rock for years (yes, I know, many have) then you have probably heard of git. Billing itself as “the fast version control system“, git is the distributed version control management system that has become the darling of the hour. It allows developers to work on-line and off-line, to host repositories locally or on the now popular github, to perform merges as the rule rather than the exception. In short, git is to version control what WordPress is to blogging. The eight hundred pound gorilla in a small room.

The problem is, I’m a windows user. Microsoft sells my drug of choice at the conner electronics store. Command line tools just are not my style. Be that as it may, I decided it was high time I caught up with the hip open source crowd and learned how to drive this thing commando (Linux) style. That plus there is the code block on github that I want to fork, but let’s not get bogged down in details!

What follows is a series of simple commands wrapped in a monkey stupid (yes, I said monkey stupid) how-to guide for git using the Git Bash on Windows Vista. I’m not going to tell you how to install it on Windows. You can Google that for yourself. I’m going to tell you the (mostly) absolute minimum needed to get up and running with git version control. If you are nice and follow along to the end, I may even share some web resources where I obtained this top secret information. No promises mind you. We will just have to see how well you behave along the way. Remember, there will be a test at the end. (There actually won’t be, but when the monkeys hear test it gets their attention!)

Navigation

Let’s begin by launching the Git Bash program. You know, Start, All Programs, Git, Git Bash. Good monkey! Now what you see is the MINGW32:~ header on what looks like a slightly off beat DOS command prompt. Sigh. The directory that Git Bash opens in is the c:\Users\your_user_name directory. Since most monkeys don’t put source code there we need to navigate to the directory of the source that we want to version. You can use the cd command (change directory for you old school DOS nerds) to navigate around your computer to find the directory where you source lives. Let’s try some commands and see what we get.

• It’s not navigation really, but to clear the Git Bash DOS prompt window we type:

  1

  clear

• Next, we can navigate using the cd command to change directory. Here we move up to the parent directory of the current directory.

  2

  cd ..

  Afterwards the prompt should show the new directory, in my case that is:

  3

  /c/Users

  In Windows speak this is the equivalent of c:\User\.

• For our example let’s assume that my source is on my e: drive and I want to navigate directly there.

  4	cd /e/lighttpd/htdocs/test

  This brings me to e:\Lighttpd\htdocs\test in my Windows directory structure.

• To find out what is in my current directory I simply type the ls command.

  5

  ls

  At the moment my folder is empty so nothing is returned. Let’s throw some files in and start to version our source.

Basic git

To start I create an index.php file with the this content.

1
2
3
4

<?php
/*My Awesome Program! */
phpinfo ();
?>

Yes, it’s amazing. I also create a test.css file, but you can put anything you want in that. Now when we run our ls command again we see the two files we created. Since git is in the directory that we want to control we can start managing our source with a few simple commands.

• To start tracking at the current project level we type

  1

  git init

• To add both our PHP and CSS files and commit them initially we type

  git add *.php
  git add *.css
  git commit -m "the monkey flips the switch"

Once you have done this you can run the ls command again and you will see that Git Bash appends the “(master)” description to the end of the directory path. This is a fancy way of git saying that it just created a .git directory right in the middle of your project directory and stored your commit there. But we are monkey stupid, right? We did not want to do that. It’s cool. We can just blow it away. For the real monkeys out there you may want to use Windows Explorer to do this. For stupid monkeys (like me) you can use the following. WARNING: MAKE SURE YOU ARE IN THE RIGHT DIRECTORY, MAKE SURE YOU BACKED UP YOUR PROJECT, ETC!

rm -rf .git

Afterwards you can just use git init again to start over and rebuild your git repository. If you did try the delete (bad monkey!) then go back and re-init, populate and commit your source. Afterwards you can run the following command to see what git thinks of your repository.

1

git status

If you added all file types in your project folder using the git add command and if you ran your commit then you should see something like this.

1
2

#On branch master
nothing to commit (working directory clean)

You have saved the day (and some source code too)! Now let’s get to programming. Go change your index.php file to contain the following.

1
2
3
4

<?php
/*My Awesome Program! */
print "My even more awesome program!" ;
?>

Now when we run git status again we see something like this.

On branch master
#Changed but not updated:
#  (use "git add <file>..." to update what will be committed)
#  (use "git checkout -- <file>..." to discard changes in working directory)
#
#        modified:      index.php
#
on changes added to commit (use "git add" and/or "git commit -a")

What happened!?! Work happened my monkey friend, work happened. Now that you are off creating the next great application git is waiting patiently in the background to save your source code or recover it for you. Let’s commit our changes since they are clearly better than what we had before! You already know the commands that you need.

1
2

git add index.php
git commit -m "now with really awesome monkey output"

Solid. You are now a certified (not really) monkey stupid git user. Sweet! git will actually do a lot of other cool and powerful things like cloning, merges, etc, but that is beyond the scope of a monkey stupid guide. When you are ready to move on to more sophisticated fair you should absolutely check out Pro Git and buy a paper copy of the book to support the site. Good luck and have fun using git my monkeys!

I like the idea of open source software. I even want to contribute to the cause when I can find an effort that I can connect with and where I can make a difference. The big problem I run into is what can I do with open source? There seem to be a few licenses out there that are in common use and they are not all created equal. I’m all about giving, but sometimes a fellow has to eat too. How do you figure out what you can and cannot do under an open source license? I decided to give the research a shot and see what I can come up with. I figured I would look at big open source projects, see what licenses they use and then research those licenses. Simple, right? We will see.

To start with, let’s see how big the list can get. Check out these two links.

1. Open-source license
2. Comparison of free software licenses

When you see the list you quickly get the idea that there are more than a few options. It’s hard to know where to start. Let’s start with the blogging software that launched a thousand blogs.

GNU General Public License (GPL) – The GNU GPL sits to the extreme left (pardon the pun) of the open source license food chain. It has a cousin, the GNU Lesser General Public License (LGPL), which per Wikipedia “was designed as a compromise between the strong-copyleft GNU General Public License or GPL and permissive licenses such as the BSD licenses and the MIT License.” From what I can tell by reading the Quick Guide to GPL v3 it seems like the GPL’s approach is free for all and always free. In other words, if you want to make any money off selling your work based on GPL software you are coding up the wrong tree.

GPL is out there and some big open source projects do use it. They include WordPress, MySQL Server, Ubuntu and OpenOffice.org (LGPL). These are heavy weight products in the open source world. Although they carry the GPL or LGPL, it seems that most of these products have commercial companies around them. Some seek to profit from services (Automattic) while others want to profit from license fees if you do anything commercial with the software (MySQL AB – Now Sun). MySQL seems more complicated when you start to look at things like the Percona Builds, but the basic idea seems hard to separate from more commercial ventures. The impression I get is companies that form around the GPL license use it as a shield to prevent anyone from having too much success using their work commercially. This attitude seems to be personified by Matt Mullenweg of Automattic fame who has this to say on the topic. I’m not making a value judgement here. Matt is basically saying free software should stay free. I get that. It just becomes very limiting if that’s not the only thing you want or need to produce.

The BSD License – If GPL is the extreme left of the software licensing world the BSD License (or New BSD License) is the extreme right. It is about as short and sweet as you can get. The core intent here seems to be open source software that can be used as the basis for commercial efforts. From what I can see it is simply that straight forward. Basically it only seems to exist to provide credit to the original author on re-distribution and to remove any implied warranty of merchantability. Lots of open source efforts that you are probably familiar with use the BSD. Some of the more notable include The Zend Framework (license), Trac (license), Django (license) and the Kohana Framework (license) to name a few. BSD is just the kind of license you need if you want to make some money. I would say it’s as open as it can get, but then I don’t think that’s exactly true.

MIT License – The MIT license is as open as you can get. It is essentially a liability waiver and nothing else. It does not have the BSD’s copyright preservation or marketing restrictions. The main difference to me is that MIT could care less what you do with both the software and the branding of the software. That seems overly open, but there are products that use MIT. One notable product is the vastly popular Ruby on Rails Ruby Framework.

It is interesting to note that some products offer a choice between licenses. Two that I noted were the jQuery Javascript Framework (license) and the 960 Grid System CSS Framework. Both these frameworks are licensed under the MIT and GPL licenses. My understanding is that the software developer / consumer is free to choose which license they will use the product under. This allows some modified work products to enter the market as truly open (GPL) or whatever the developer wants them to be (MIT). If I’m being honest it seems to me like the teams simply could not take a stand so they decided to pass the buck on to the next developer. It’s not a bad solution if you want to be many things to many people. That is, after all, what it seems like open source is all about. Having it your way.

As the Habari project team states , “None of the packages we’ve tried have really satisfied us, so in the fine tradition of open source software we’re trying to scratch our own itch.” Interestingly enough, Habari blogging software uses Apache License Version 2.0. My quick scan (the legal jargon put me to sleep) is that Apache is a more verbose and slightly more limiting version of the BSD. That is an over simplification, but you get the general idea. This license is also reasonably popular and is used by (among others) the Apache HTTP Server. If you think the license might be right for you then by all means give it a read. Also if you are having trouble getting to sleep the same advice applies

So where does all this leave us? If you’re like me it leaves you confused. Although we briefly covered some of the most popular licenses there are many more out there to chose from. You can find an exhaustive list (and some good information) on the Open Source Initiative web site. Ultimately only you can decided what is right for your project and what open source products are correctly licensed to support your project’s goals. I recommend getting to know them better. If you start to pay attention to open source licenses you begin to get a glimpse into the philosophy of the development teams. That may prove to be as helpful to you as the license itself in determining if each solution is a good fit for you. Good luck!

Although I’m sure there are more than this, here is quick run down on some PHP ORM solutions that I was able to find with limited searching. The first 2 seem to be the most popular ones. If you know of another good solution please post a comment.

• Doctrine
• Propel
• Outlet
• RedBean
• dORM
• Jelly
• Kohana ORM
• Sprig
• LightORM
• Flourish ORM
• php-activerecord
• CoughPHP
• Torpor