For the past couple weeks I’ve had fun asking that of people. I’ve asked it of prominent PHP developers, customers, major enterprise software organizations, and product evangelists. The only conclusion that I’ve come to is that no one has a clue. In order to add to the chaos, I thought I’d offer my opinion.

An enterprise application is a system or products that live primarily to combine and extend an organization’s existing data, functions, and systems to help people do their jobs better.

In terms of attribution, this overlaps quite a bit with the definition given by my friend and colleague Josh Holmes, a Platform Evangelist with Microsoft.

To explain this further, let me put some boundaries on my definition:

First, the size of the team doesn’t matter. Facebook has hundreds of PHP developers on staff, but few would call it an enterprise application. That doesn’t discount the ability of their teams. Some of Facebook’s technology is amazing.

Next, the size of the application (lines of code) doesn’t matter. Most video games – especially MMO’s – have millions of lines of code, some may even have billions.

Next, it’s not the amount of traffic/usage that defines enterprise. The ‘I Can Haz Cheeseburger’ network is something like an estimated 178% of the web’s traffic.

Finally, it’s definitely not the development process. With the advent of cheap/free unit testing, deployment, and infrastructure tools, the most cash-strapped startups can have rock solid processes.

I think the key to all of this is intent. The goal – not necessarily the result – of most Enterprise Development is to make someone’s job easier or more effective by pulling together information and presenting it in new ways. Business intelligence, ERP, CRM, and reporting systems all fit into this category.

So why is this important to web2project?

I’m writing about this concept in this space because this is key to our Vision for web2project. Our goal is to make and improve the system based on real-world feedback, needs, and requests. We already work to pull together different data sources whether you consider the Project Importer to import Microsoft Project XML or the iCalendar feeds to publish data where the team members need it. Further, we support LDAP authentication so people don’t need to remember yet another password. Adding IIS support in January was a small but significant step.

Our Vision going forward is that web2project can be dropped into any organization’s existing infrastructure and simply work. It should be able to authenticate using the organization’s architecture. It should be able to retrieve from and broadcast data to CRM and billing systems. Assuming it is technically feasible with PHP, it should support the database system and web server software your organization already uses. Finally, and most importantly, it should make your team members’ jobs easier and give them better information.

If we fail in those things, web2project becomes a toy, not the enterprise tool it should be.

As of 22 September 2010, web2project v2.1 is officially released! You can download it from SourceForge now.

For Project Managers, there are not a huge number of tangible improvements. This was mostly a cleanup release:

• The most important part is that now a User can add Tasklogs for people other than themselves. When you create or edit a Task, you can denote “Allow users to add task logs for others” which allows just that. Users can add hours for anyone currently assigned to work on the Task. The system tracks who logged the time for audit purposes.

For Developers, we had a significant number of cleanups related to timezones, Gantt chart creation, and miscellaneous things here and there:

• The most important part are some cleanups related to the contact_methods refactoring. There were a number of issues that made it into the v2.0 release that are now closed.
• More useful in general was a complete refactoring of the Gantt chart creation. One of our goals for v2.2 is to supplement the current image-based (jpGraph) Gantt charts with both a jQuery and a Flex/Flash-based option.
• We added a significant number of Unit Tests for the system in general but focused on the PEAR/Date and CDate classes specifically. We hope to replace PEAR/Date with core PHP functionality in coming releases.
• We resolved a number of browser compatibility issues for IE 8.
• iCalendar generation has been updated to create VEVENTS that pass validation as per the formal specification.
• We moved a number of duplicate and oddball functions into the deprecation area for refactoring and eventual removal.

For anyone who might be interested, the big time sink during this release was of a legal nature. After the battle between WordPress and the Thesis theme played out and how the GPL could be interpretted, we investigated what it would take to change to a BSD-based license. The good news is that it will be possible – more to follow – and the bad news is the amout of effort involved.

Once again, some great community members stepped up and did a great job in reporting issues, testing fixes, and generally offering insight and sanity checks. Special thanks goes to opto and figgles.

In summary, we closed 38 issues including 3 crash-level issues, 20 minor issues, and 4 features. As always, these are just the formally reported issues and don’t include smaller items that were reported via Twitter, the web2project forums, and other means. If you want to explore everything of interest, check out the web2project v2.1 Release Notes. And of course, if you’re looking for ways to collaborate with us more easily, you should check out our web2project git repository.

You can download web2project v2.1 from SourceForge now.

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

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.

As of 01 April 2010, v1.3 of web2project is live.

This release was focused almost entirely on bug fixing and preparation for the coming v2.0 release in June. Since the v1.2.2 release in January:

• First, we added another 35 Unit Tests covering core functionality in the Tasks module. While there are still lots fo things that need tests, Trevor has does some amazing work and should be applauded for it.
• Next, we’ve done quite a bit of cleanup to the Tasks module itself. Now moving a Task from one project to another will cause both projects’ percent complete to be recalculated.
• Next, the upgrade process has been moved out of the /install folder and into the System Admin. Further, the System Admin page notifies administrators if database updates should be applied. This ensures that only properly permissioned users can apply upgrades.
• Next, we added “minification” to the Javascipt and CSS which reduced the corresponding filesizes by 80% and 33% respectively.
• Next, we created a number of Views Helpers. These helpers handle auto-linking fields that have url’s or even email fields. On the other side of things, we’ve added validation for email and url fields. If something is supposed to be a url, it will be. Further, description fields will respect character sets including umlauts and other non-English characters.
• Finally, we added deprecation warnings to a number of methods and functions that will be removed in later releases.

In summary, we closed about 25 items with ranging from 3 crash-level issues to 14 minor bugs. Once again, those are just the formally reported issues. If you want to explore everything of interest, check out the web2project v1.3 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.

This release came a little later than planned, but due to conflicting schedules, it just had to happen. Regardless, we’ve already sketched out v2.0 and plan to get back on track with the September v2.1 release.

Late last month, I received some bad news about web2project…

It turns out that web2project was vulnerable to a handful of select Cross Site Scripting (XSS: definition) vulnerabilities. While the attack vector was pretty specific to being an already authenticated user, it had the potential to be a major problem in a poorly configured system.

On the positive side, I say “was” because within 10 days of being notified of the problem – and the same day the vulnerability became public – we had a patched release out the door and available to users. We’ve spent the past month since encouraging them to upgrade. Of course, we further benefit from the fact that although the vulnerability does affect us, we’re not named in the report.

On the negative side, it did take us 10 days to close the vulnerability. The patch itself was available a few days earlier via Subversion but it might not have been enough. Further, we didn’t explicitly notify our users of a need to upgrade but since it was rolled with a handful of other major fixes, it appears that many people have upgraded already. Once again, we benefit from the very specific attack vector.

To make this process easier and faster in the future, as of v1.3, we can already detect if upgrades have been uploaded but not applied. For an upcoming release, we’re implementing a Drupal/WordPress-style means of notifying existing administrators thatan upgrade is available. In the meantime, watch this space or web2project’s page on Sourceforge.