If you're not part of the Joomla community - I'm not - you might have missed something significant that happened this morning (This morning being 12 midnight on 02 July 2009):

The Joomla Extension Directory (JED) went 100% GPL. [1] [2]

While this doesn't seem like a big deal to many, the change is interesting.

Previous to this, as long as a given extension's license was Open Source Compliant (MIT, BSD, GPL, MPL, etc, etc), it could be included in the JED.  It provided a one-stop shop for extensions and was the single place where nearly every extension resided.  It's powerful and helpful for a community to have a single place where everyone can go for information.

But now that's changed...

I've been quiet on web2project for the past few weeks, but I thought I should share some of the latest developments.

The single biggest improvement currently is the inclusion of Unit Testing.

Unit Testing has been on the agenda for months and years.  The problem was that something else - often bugs, sometimes new features - would creep up and push it off the todo list.  And then something happened at php|tek this time around:

I met Trevor Morse - lead developer of Azorus and the founder of the Nova Scotia PHP Developers Group.

Over the last few months, I've heard a common thread in a number the various Open Source communities I participate in or watch:

How do I get involved with the Open Source Community?

When someone considers how to get involved, they always think first and foremost about code.  They believe that the only way to contribute or participate on a project is to write code.  Well, not quite, so the answer becomes quite simple:

It depends.  What are your skills and interests?  That's right, it's not all about code!

First of all, yes, a project needs code that eventually get released.  But code is just one part of the Open Source Community.  Yes, it tends to be what we talk about, what we spend most of our time on, what starts/encourages licensing arguments, and what eventually gets released, but the other aspects can be even more important.

If you were paying attention a few months ago, you know that for php|tek 2009, MTA put together a free webcast series. We had great turnout, feedback, and success with them, so we're doing it again:

We have the FREE CodeWorks 2009 Webcast Series!

It works basically the same as last time around.  About every other Friday over the next three months, we'll have a ~30 presentation starting at 1pm Eastern Time.  We tend to start on time, so don't be late.  But if you have to miss it or are running late, the video and slides will be posted afterwards.  Where?  We're not sure yet, stay tuned.

Years ago I worked for a company which shall remain nameless.  They collected data on everything:

We had to swipe cards to get in the building in the morning and again at lunch.  Our computer login and logout times were checked.  We had to remain 95% billable (no kidding) while the maintenance workers were tracked based on how long a service ticket was open and how long the task actually took.

For quite a while, they weren't doing anything with this data... and then someone started talking about "continuous improvement".

The underlying idea of "continuous improvement" - regularly analyze collected data to see what can be improved - makes quite a bit of sense.  After all, the concept is no different than optimization issues or bottleneck analysis we do.

Quite often when I'm pouring through an old codebase or evaluating a new codebase, I run into a variety of things that drive me nuts.

First, there are quite often duplicated/similar function names like doSomething(), doSomething1(), and doSomething2().  Every single one does something very similar to all the others but normally there's a special case handled in each one... or more annoyingly, a not-so-special (aka normal) case.  As confusing and annoying as those sound, they're not the worst.

Next, there are often functions that are basically big case statements that perform completely different behaviors based on a single parameter.  As wasteful as those often are, they're still not the worst.  (For reference, this is often called Conditional Complexity or Combinatorial Explosion.)

In recent days and months, I've been left pondering a question that initially I thought was simple... but seems to be getting more complex every day:

What makes an unconference an unconference?

There are a few qualities that I've always associated with an unconference and after an exchange with Aaron Brazell and Geoff Livingston last week, I thought I'd share them here.  I happen to respect them both and don't mention them to criticize.. just to contrast some differences.  In no particular order:

A free/cheap cost to attend - While "cheap" is a relative term, I believe the key to this one is making it accessible to people.  For example, BarCamps are usually free.  PodCampBoston was bitten by this one a few years back when shirts were purchased based on 1500 signups and only 700 people appeared.  Ouch. The natural - and reasonable - reaction to this was to charge a fee and PodCampBoston did the following year.