When we start projects, we often follow the naming conventions of our frameworks without even thinking about the "Why?" It almost seems silly to ask until you run into a - hopefully, legacy - codebase that has an incomplete or inconsistent scheme.

Unfortunately, web2project is one of those codebases.

For those just joining us, we forked web2project in late 2007 from dotproject which itself was started in mid 2000. Therefore some of the code goes back nearly 13 years all the way back into the PHP 3 days. Therefore, there's a little.. cruft. And naming conventions are just one piece.

First, we've had a simple Object Relational Mapper (ORM) since the earliest days. It handles our object to database (and back) conversion with no configuration. While there are many arguments for and against ORMs, it works and makes things simple.

We're at that time of year where everyone wants to start something new. We have a flood of articles and blog posts about "what I'm going to do differently this year" and everyone wants to [choose: lose weight, read more, get out of debt, get that new job, etc, etc]. If they're lazy, this urge will last about a week.. aka it's probably done by now. Alternatively, if they're motivated, they might make it to February.

At the end of the day, it doesn't happen because starting something new is HARD.

Alternatively, in software development, we're spoiled. We can write a single line of code and do some interesting things. If we add a framework, that single line of code is backed up by thousands.. and can do even more impressive things. At Twilio, it's cool watching someone get excited that their three lines of code just made their phone ring. Unfortunately, we can take this too far..

One of the most common configurations out there is related to allowing web2project users to have access to only specific companies. While it's not as simple as saying "users should only see things from their own company," it's not as complicated as you might think. Here's how I've done it for various groups.

If you start with the basic roles, here are the step by step directions:

Role: Project Worker

Non-Admin Modules - Allow - Access, Add, Delete, Edit, View

Companies - Deny - Access, Add, Delete, Edit, View

Reports - Allow - Access, Add, Delete, Edit, View

Explanation: This gives access for a User to do anything they want on any of the non-admin modules *except* for Company. But since all of my Projects are assigned to a company, they can't actually see anything other than the navigation menu and empty screens.

When web2project was first formed in November 2007, I was recruited to work on the community side of things. I had previously earned a spot on the dotProject team by performing support in the forums, blogging, writing the occasional documentation, collecting user feedback, and tracking bug reports, so it was familiar ground.

At the insistence of John Mertic - Developer Liasion of SugarCRM - whom I met in January at PHPBenelux 2011, I submitted and was accepted to speak at SugarCon 2011 next month. My session - Transparent Collaboration - covers a part of open source that drives most of us up the wall.. integration. Here's the marketing version of the synopsis:

A few weeks ago at the PHPBenelux Conference, I gave my presentation on the rebirth of dotProject as web2project where I covered one way of rebooting a project. But after catching Elizabeth Naramore's talk on "Technical Debt" again, it got me thinking..

Within web2project, we made the deliberate decision to work on our technical debt. Even after 2 major, 5 minor, and one patch level release, we still occasionally find issues ranging from annoyances to things that will require major refactorings*. Either way, since we're steadily documenting them, we're constantly getting a better picture of the state of the system and its strengths and weaknesses.

Alternatively, we could have trashed the code and started from scratch..

The classic example is Netscape 5.