Note: The following is not legal advice.. it is an explanation of legal advice. If you need legal advice, hire an attorney.

Earlier this week, a student I'm mentoring asked about my "IP Agreements at Hackathons" post. He plans to attend the event in question and asked me specifically about the IP agreement and what it could mean for his startup.

This blog post heavily quotes my occasional collaborator Cal Evans. The quotes are used with permission. The link to the original is at the bottom.

Despite the problems with sexism in the tech community in general, the PHP community has had it pretty easy. While there are potentially a number of reasons, the founder of phpWomen Ligaya Turmell shared it this way (paraphrased from Cal):

The PHP community has not had the problem with sexism that other communities seem to have but that is because from the early days, we have had strong women role models. Women like Lara Thomson, Sara Goleman, Liz Smith, and the like have played such a prominent role in the community that no, we’ve not had as big of a problem.

So I am honestly surprised to see this promoted at a conference:

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.

Over the past decade, I've started, been employed by, and advised a flock of startups. More recently, I've been an advisor at events like Startup Weekend, Lean Startup Machine, and the new Longhorn Startup Program at UT.

One of the big pushes in recent years - I suspect primarily due to Lean Startup - is customer interviews. At some point during these interviews, the "would" question comes up. Generally it's structured something like this:

"Would you like a product that makes X better?"

And every group celebrates that "95% of our customers said yes!"

That's great, right?  Well.. let's break this down a bit.

First of all, until they give you money, they're not a customer. That's it plain and simple.. so therefore, these are potential customers or potential users but not customers.

Almost six years ago now (whoa!), I was a regular agitator in the Washington, DC PHP Developer's Community (DCPHP). The community was probably a hundred people with skills ranging from total newbs who couldn't spell PHP to contributors to major open source projects. At that point, we consisted solely of a monthly presentation-style meeting and a mailing list.

And without fail, traffic on the mailing list started getting.. aggressive.

To be clear, there was nothing wrong with the group, that's just how email goes.

Email is a lossy way to communicate. You don't see the smiles or frowns, hear the tone of voice, or see the frustration that elicited that response. And misinterpretations are going to happen. Now take software developers - a culture known for being direct (aka blunt) and sometimes inappropriately so - and trouble is guaranteed.

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..