Keith Casey on PHP

For those of you just tuning into the WordPress/Thesis battle, here is the current - as of 19 July 2010 - state of things:

• At some point recently, the servers of Chris Pearson - owner and distributor of the Thesis theme for WordPress - had a vulnerability on his server and the latest releases of Thesis were compromised.
• When that came to light, Matt Mullenweg - head of the WordPress project, founder of Automattic, and founder of the WordPress Foundation - has previous stated that "WordPress Themes are GPL too!" sent a simple Tweet: "This is what happens when non-coders think they can code."
• In a matter of moments, that was being reTweeted, argued, discussed, blame was being spread around, and things started getting heated.
• Andrew Warner had the insight to get both Chris and Matt on the phone for a Mixergy interview. Chris came off poorly (at best) when he "explained" that the GPL didn't apply to Thesis and further claimed that he was one of the three most important people in WordPress. Things exploded from there.
• Matt raised the stakes by making a public offer to buy any existing Thesis customer a new premium theme from somewhere else. And then started tweeting individual Thesis customers making the offer.
• And igniting things further, Andrew Nacin - another core WordPress developer - and a few others (Andy Peatling, Drew Blas) started digging and found snippets of GPL'd WordPress code in Thesis.
• Next, a commenter on Matt's update post (titled: "Syn-Thesis 1 and Chris Pearson") who happened to be a former Thesis developer admitted to copy/pasting things from WordPress because he didn't understand the license.
• Finally, Chris says that the offending code has or will be removed but Mark Jaquith (and the Drupal and Joomla communities) wrote "Why WordPress Themes are Derivative of WordPress" so offending code or not, it doesn't matter.

So what does this all mean to the community?

Good question... As my partner Marco Tabini notes in "WordPress, the GPL, and cherries on top" everyone has an opinion on what the GPL means and what its ramifications are but since there's no legal precedent, it's just a best guess... and there has yet to be a precedent to solidify an interpretation. In the meantime, the most common interpretation is based on the Software Freedom Law Center's opinion and the GNU FAQ. Here's the problem with that:

The FAQ is not part of the license and not distributed with it. It is stored on a website without version control or an audit trail on who might have modified it when. By all accounts, it is less reliable than Wikipedia because even errors can't be fixed.

Feel free to cite the FAQ all you want.. no one ever explicitly or implicitly agreed to that interpretation.

If you combine this with Matt and Mark's opinion that themes are GPL because they're dependent on WordPress code and datastructures to have meaning, what are the ramifications of this interpretation?

• What is the threshold where including code crosses from "Fair Use" into "now this must be GPL"? While there are lots of ways to do things in PHP, if there are Best Practices, we'll all tend to reach similar results.

• For client work, if copyright isn't transfered with the delivery of the code, isn't this distribution? And if so, doesn't the client work have to be GPL? Or if you transfer the copyright at delivery, what about the demo versions? Did you send them copies of the code before you transfered copyright?

• If the client work does have to be GPL, do you have to make it available to anyone who asks for it? Since the GPL doesn't requite a "public disclosure", it's possible no one would know to ask.. but what about employees of either group? If it's "privately" GPL, would an employee be within their rights to take and use a copy?

• What does this do to Non-Disclosure Agreements? If the code must be GPL and I have to provide a copy to whoever might ask, how can I agree to protect the secrets of my customers?

• What about a book that covers GPL code and datastructures? What if the book goes as far as including snippets of WordPress code itself? While the book may be able to physically exist and function independent from the code, it doesn't have any meaning without the core system. Should Lisa Sabin-Wilson GPL her book "WordPress for Dummies"? Does Aaron Brazell have to GPL his "WordPress Bible"?

• A given WordPress post consists of a title, body, and a category or some tags. It's pretty trivial to turn that into a post on the page without using WordPress at all. But what about a complex data structure that only has meaning once it is transformed by the core code?

That last question is the point of the discussion we've had within the web2project team recently.

If you're not familiar with web2project - or its parent dotProject - the data in the database doesn't mean much by itself. The core code must retrieve the data and process it to express a project plan in a meaningful way. It does the same to files uploaded, tasklogs stored, and a number of other things within the system.

Therefore, since the data is wholly dependent on the core web2project code, does the data itself have to be GPL?

And that's why a few weeks back, we started the process of changing licenses from GPL back to BSD as dotProject originally was. I'll go into more detail on the process and due dilligence involved, but know that we've been on this for quite a while and are working to have it fully resolved before the next web2project release.

Disclosures: I don't have an interest in Thesis as I've never used it and don't know Chris Pearson at all. I use Automattic's Akismet for blocking spam on a number of Drupal sites. Finally, I am using WordPress on the web2project site relaunch and was a reviewer in Aaron Brazell's WordPress Bible and wrote the foreword. My biggest concern in all of this are the larger implications on web2project and GPL projects in general.

Update: To be fair, a great deal of inspiration for this post came from Ed "Funkatron" Finkler and his session at phpWorks 2008 Picachu pitch-at-ya peek-at-you lightning talk called "Users are Assholes" and later by Matthew Weier O'Phinney's lightning talk called "How to get kicked off my Project." Thanks for the fodder guys!

On all sides of software development, there are annoyances. Some of them go beyond annoyances and into pet peeves. Some of them go beyond pet peeves and incite open war within projects and communities. After witnessing a number of these rants - from developers and non-developers - and even sharing a few myself, I thought maybe I could make the situation better.

Therefore, I present here for comment:

The Ten Commandments of Open Source Software.

0. Thou shalt not ask questions without basic research including documentation and the Google.

I. Thou shalt realize that most developers work on passion and freetime. Thou are not paying them.

II. Thou shalt not criticize code and architectures before seeking understanding.

III. Thou shalt not use the phrase "this should be simple" unless thou has confirmed it as such.

IV. Thou shalt apply patches and updates in a timely manner. Further, thou shalt have a vague idea of when the next release is due-eth.

V. Honor thy developers and designers.

VI. Thou shalt include specific error messages and screenshots when thou hast problems. Thou stating "thy software sucks" is not helpful and angers the Funkatron.

VII. Thou shalt not murder.*

VIII. Thou shalt not copy without respecting both the license and the terms within.

IX. Thou shalt not covet the features and functionality in thy neighbor's software.

Did I miss any?

* No, I'm not kidding.

As of 29 June 2010, web2project v2.0 is officially released! You can download it from SourceForge now.

Although this release had lots of bug fixes, the primary focus was on a few specific new features and major pieces of functionality. You can read the full v2.0 Release Notes, but in my opinion, the six most important items are:

• User-based Timezones: Everywhere a time is used or displayed within the system, it's now stored in GMT/UTC and presented in the user's local timezone. If you set a meeting for 5pm America/New_York, someone with America/Chicago timezone will automatically see it at 4pm. If you have team members spread across timezones, this is vital. Lots of thanks to Derick Rethans - the master of all things time-related in PHP - on his numerous presentations on DateTime and Timezones. His information made it possible.
• Unit Tests have come a long way since the v1.0 release. We had zero at that time but Trevor Morse - founder of the Halifax, NS PHP Group and core web2project member - has led the way to 240+ tests focused on the Tasks and Projects classes.
• Subprojects are now Useful: Previously you could denote one project as a subproject as another but it didn't really do anything, it was just presented a bit differently. With this release, when you assign a project as a subproject, now it creates a token task within the parent project. This token task takes on the start/end dates, duration, hours worked, and percent complete of the subproject. As the subproject updates, the token task updates. Even more usefully, you can use the Token Task as a dependency for other tasks in the parent project. That all sounds complicated, so just try it out.
• The class structure has been completely restructured: While this won't be relevant to 99% of our users, it makes it much easier to add standalone frameworks - like the Zend Framework or whatever - to the system for other functionality. On a related point, web2project now supports the naming conventions put forth in the Framework Interoperability Group. This will also allow easier third-party authenticators for systems like Drupal, Joomla, or WordPress.
• Audit Logs - We cleaned up the core system objects to provide historical logging of all CRUD operations. Any Add On modules that use the core objects will get this functionality by default.
• Added an 'update checker' - This is a regular script which runs to notify the System Administrator that a new release is available and collects basic system information. This was modeled after Drupal's update functionality. No sensitive information is collected and this can be opted out of via the System Configuration.

A number of community members stepped up and did a great job in reporting issues, helping test fixes and release candidates, and generally being insightful. Special thanks goes to opto, adolfo, zbyszek, and egemme. Without them, v2.0 would not be as solid, useful, and generally as bug-free as it is.

In summary, we closed about 79 items with ranging from 15 crash-level issues to 42 minor bugs. Once again, those are just the formally reported issues. If you want to explore everything of interest, check out the web2project v2.0 Release Notes on our wiki. And of course, if you're looking for ways to share your code more easily, you should check out our web2project git repository.

You can download web2project v2.0 from SourceForge now.

* And yes, I always wait a few days to announce the releases in case we have to make a patch release. ;)

It's been a week since tekX completed and there are a number of other tekX writeups to read but I thought I'd share one last one from a different point of view. To add some context, I'm not the guy that signs the contracts, approves the expenses, schedules the sessions, arranges the speakers, or anything useful. Due to other project commitments, I basically served as backup for some of those things and then as social chair for the evening events.

First off, I'm proud of our first time tekX speakers. Easily half of the speakers had never spoken at a tek before, off the top of my head that includes - Bill Karwin, David Strauss, Jason Austin, Josh Holmes, Kanwalijeet Singla, Kristina Chodorow, Matt Schmidt, Matt Turland, Ryan Stewart, Sumit Chawla, and myself. Since tek is the Community Conference and it tends to be incredibly technical, it takes a different mindset than many of the other conferences. Even better, a few of those people were first or second time conference speakers period.

Next, based on the feedback from Joind.in, the sessions themselves were consistently solid and "good" at minimum. The speakers did a good job of choosing topics, content, and styles that sparked the interest of attendees. Even better, I regularly heard "I never thought of it that way" in the hallways and at meals. That gets me excited. When someone thinks of something differently or new because of an idea of perspective that a speaker introduced, things can change. They can improve what they're doing. Their organization can improve. The community can improve. Everyone wins.

Next, there were a few sessions that stood out as particularly relevant and interesting. Josh Holmes' opening keynote on The Lost Art of Simplicity. Although I wasn't there, Kristina Chodorow's three hour tutorial on MongoDB topics was received incredibly well and generated lots of discussion. Ryan Stewart's session on the last day included an overview of Data Visualization gave a good overview of tools to build graphs and charts. And despite being an Adobe guy, he did talk about Canvas and non-Adobe options. Finally, I've heard great things about Lorna Jan Michell's session "Open Source your Career".

Next, we had some great sponsors. In alphabetical order: Adobe, Microsoft, SQLyog, and Zend each contributed good things ranging from happy hour drinks to toys to presence to heavy involvement and planning support.

Next, the internet stayed up. No, seriously... it did. We ran out of IP addresses a couple times and it dropped to 1-5kbps at least a couple times, but it was still up. I'm not sure what was so different this year, but it worked.

Finally, once again, the people were amazing. The energy, the excitement, the comradery, the chaos, and the passion was evident. Sure, it takes some people some time to warm up, but once people start connecting, it's hard to avoid it. After tek last year, Trevor Morse (of web2project fame) started the Halifax, Nova Scotia PHP Developers' Group, but this year, this exploded. I moderated a Community User Group Panel with Michelangelo van Dam, Rafael Dohms, Lorna Jane Mitchell, and Ben Ramsey... and apparently, it pushed a few people over the edge to start their own groups.

And with that, I'd like to announce:

Chance Garcia started a local Bloomington, Indiana PHP Developers' Group.

Jeremy Kendall kicked off a the Memphis, Tennessee PHP Developers' Group.

Chris Tankersly started a semi-regional Northwest Ohio PHP Developers' Group.

These guys are taking a step out into their communities with the goal of connecting local developers, employers, recruiters, and everyone else with the goal of making their own skills - and the skills of the people around them - better. If you're in either area, join and help them. If you know people in those areas, pass the word. Even if you're not local but want to lend support, join their lists and contribute.

Even the biggest groups started with a single person with an idea.

During my Live Coding sessions at TEK·X* last week, one of the questions that came up repeatedly was:

Events... what are these Event things and why does Flex work like that?

When you initially dive into the world of Flex development**, most PHP'ers will quickly notice something weird. We're out of the world of Request/Response that we know and understand and into an odd world of Events, Listeners, and Publishers/Subscribers where things just don't play well together.

The familiar Request/Response process is similar to going through checkout to the grocery store. The cashier is idle until a new customer appears. The customer makes their requests, the cashier transfers a specified amount from one account to another, and the customer leaves with their results. As more customers appear and the line gets longer, the stores scales horizontally by adding more cashiers. It all scales quickly and easily with minimal effort because grocery store cashiers are a shared-nothing architecture.

Alternatively, the Publisher/Subscriber (or Observer) pattern is similar to waiting at the airport. When you're waiting for a flight, you sit near your gate and wait for an announcement. In the meantime, you might grab a cup of coffee, use the restroom, check email, or make phone calls. The people around you do the same. As announcements are made, some people board their flights or swear at gate agents but regardless until your announcement, you don't care. But once you you hear your announcement, everything changes. You finish whatever you're doing and take action.. along with anyone else listening for the same flight.

This is the core of Event Driven Programming.

Flex** works the same way. As you create elements and functions/methods, they listen for different Events to "fire". Once the Event occurs, all the Listeners attempt their task. The vast majority of these Listeners will not interact with one another but in some cases, Events will fire other Events.

A common task - like Uploading a File - will consist of a number of these Events:

• First, we have to select the file to upload. This could be done via a drag and drop or an explicit file browser option. Either way, the system sits there and waits until a file is selected.
• Next, we need the file to upload. If it begins immediately - like with Gmail - it probably fires from the previous event. Otherwise, it's likely from a user hitting a "Send" or "Done" button.
• Next, we'd like to provide feedback to the user. Since we know the file's size and we can find out how much has been sent, we can calculate a %-complete to update a progress bar.
• Finally, we need to know when the upload is complete. Most likely we have some sort of "WoohooFileUploadComplete" Event we can capture and let the user know. Hopefully, we'll also get back messages from our destination with error messages/status and we can pass them along for the user.

When you stop to consider it, many of the tasks our code performs can be broken down the same way. I believe the primary reason we don't think of it is because the vast majority of our code is entirely on the backend without the ability to even see or capture our events. Obviously, client side technology like Javascript blurs the line, but the concept is the same. If you're venturing into this world, read up on the Publisher/Subscriber Pattern and the Observer Pattern and figure out how to make your code - both on the frontend and back - play nicely together. Jason Sweat's book on PHP Design Patterns is a good place to start.

* The Live Coding in Flex session went amazingly well. I got a number of great questions and a few people were following along typing exactly what I was as I went. Yes, I had some minor technical issues but the audience was incredibly helpful in pointing out my mistakes. Over. And over. And over again.

** The Publisher/Subscriber model actually applies to most if not all desktop development. It's also familiar to the Javascript guys who work with onClick, onLoad, and all those familiar event-related sounding actions.

Disclosure: Through Blue Parabola, we're working with Adobe and Flex in a number of things. Regardless, I choose to explore Flex for the first time long before that.