Phil Wylie

WordPress web developer for iWeb, cider drinker and cat owner

Is it right to seek out GPL code for free?

Happiness little child relaxing outdoors

Andrew Fielden presented a talk at August’s WordPress Birmingham meetup in which he discussed GPL in the context of WordPress and the WordPress ecosystem of premium themes and plugins.

It was a thought provoking talk and it reminded me of a discussion I’d had that very week. I’ve summed up my thoughts here as I’m not sure I was able to fully articulate the ethical conundrum over Twitter!

I’d like to thank Andrew for again presenting at WordPress Birmingham. It’s always a pleasure.

We’re building a niche music download service, making use of WooCommerce and it’s virtual, downloadable products. However, at the scale we’re working at, local storage of the distributable files is simply not feasible.

Amazon S3 is one of the most popular “cloud” storage solutions. However, it was decided an internal solution would provide us more control and accountability.

I was in a meeting discussing an integration between WooCommerce and our internal distributed storage platform. We looked at the Amazon S3 Storage WooCommerce extension. It’s a plugin which provides the equivalent functionality to what we were trying to achieve.

It was during this meeting where I mentioned WooThemes were GPL, at which point it was implied that we could therefore just skim through the code. That it would be publicly accessible. Looking over the WooThemes page, the licensing was not made clear. We just bought the plugin at $29 and picked through the source to find the right hooks to build our own integration.

In this instance, I can’t be sure how much time was actually saved by making use of the extension. But it illustrates the ethical question I’m interested in. If you’re potentially going to save many hours of research/development, is it right to seek out the source code for free?

Authors are not discouraged from selling access to GPL software and are not required to make source freely available. And for me, I think this is where context is important. There is a difference between someone throwing their code up on GitHub for the world to see and a business selling access and support.

If code has been made available, released on GitHub for example, it’s fair game. That feels fine. If you’re working on a personal project, grabbing source code for educational purposes, I can see the freedoms granted under the GPL are beneficial. I wouldn’t feel bad going out of my way to get hold of open source code from a “premium” plugin/theme.

Where a company has chosen to licence their software under the GPL and has an intended distribution channel, such as their own online store to sell access and support. For me, if you’re going to make use of that code for profit, it feels like the right thing to do is reward the author for their work. Perhaps in the hope they’ll be incentivised to maintain and update their software.

It’s an ethical conundrum. I’ve tried to sum up how I feel, rather than what is legally permissible. Because of course, if an author has chosen the GPL licence and someone does subsequently make their source freely available. At the end of the day, that’s the nature of the licence. The freedom it gives. If the thought never crossed the authors mind, if that wasn’t the authors intention, perhaps they should have chosen a more restrictive licence.

 

It’s time to discuss the bits in-between

mother with  teen daughter having serious talking in living room
To know how long something will take to do before doing it, is notoriously hard. Yet, as web developers, we’re often asked to give time estimates. In my experience, estimates become quotes which then become deadlines. Therefore, estimation is stressful. Estimation is difficult.

With a small job, it’s pretty easy to guesstimate. You know you have a development site ready to go, the project setup in your IDE and all the server credentials are plugged in ready to push your work live. A small change can be made, tested and pushed live fairly quickly. There isn’t much to go wrong, so it’s simple to estimate.

When dealing with a larger job, or an entire project, it becomes more difficult to accurately estimate. The technique I use, is to break down all the back end functionality, all the front end work and put a time against each task. This process helps break down a complex system and allows me put together a sensible time estimate.

Let me introduce you to bits in-between

Bits in-between are those unforeseen, necessary tasks which tie a system together. They’re the bits you don’t think of when breaking a system down. It’s the research, the trial and error, the page refreshing between code changes, the testing and committing work into version control (with a description decipherable by other humans). Outside of the programming itself, it’s the discussion, the unknown number of emails back and forth between you, your project manager and the client, signing a ticket off and finally, completing a timesheet entry.

The concept goes… when estimating a small job, there are not many bits in-between. The larger the project, the more bits in-between need to be accounted for.

In my mind, bits in-between are different to contingency. Contingency is a buffer added to an estimate when putting a quote together. It’s a different problem, to understand the complexity/risk involved and to quote accordingly.

Estimation isn’t an exact science but its part of the job. It’s certainly not something I was taught about. We learn by experience, and I do believe it gets easier, or, at least, less stressful. Over time, you can get a good feel for how much time those bits in-between can add to a task.

When asked how long something will take, it’s tempting to come back with the first roughty figure which pops to mind. I’d say, don’t be afraid to take a step back. In your mind, the coding itself might just take a few minutes. However, what you should come back with is an overall picture, including the bits in-between.

How to protect your WordPress site

Computer hacker cracked security password. Bald smiling computer hacker typing computer keyboard.
I recently contributed towards an article on WordPress security and thought I’d write up my advice in full over on my blog. This is particularly relevant in light of recent vulnerabilities in WordPress and a number of high-profile third party plugins.

The most important steps you can take to secure your WordPress site are not necessarily specific to WordPress. Good password practices and keeping your software up-to-date are often overlooked. In my experience, the root cause of security incidents tend to be a trusted administrator with a bad password or an exploit in an unpatched, third-party plugin.

The basics of security

Password security

A strong password doesn’t use dictionary words, it’s made up of a combination of mixed case letters, numbers and symbols. It’s important to use a unique password for every website. Not only because a security breach on another site could give up your password, it could also make it possible to access your email and therefore an attacker could request a password reset from your WordPress install.

Password management

I’d strongly suggest looking into using a password manager such as 1Password. You’ll be able to generate strong passwords and not have to worry about remembering them all. There are also tools around which limit the number of incorrect login attempts. Thwarting automated password attacks. If you already have Jetpack installed, check to see whether Jetpack Protect is enabled, otherwise look into something like Limit Login Attempts.

Keep all your software up-to-date

In terms of keeping software up-to-date, WordPress has a built-in update mechanism to keep itself, it’s themes and plugins updated. Running the latest version of each means you’ll benefit from new features, bug fixes and crucially, security patches.

You can access the Updates screen within the WordPress Dashboard to see and install available updates. The WP Updates Notifier plugin can email you when an update is made available for your WordPress site, saving you from having to manually check.

Managing multiple WordPress sites? Use the tools available

If you’re looking after a number of sites, there are some brilliant remote management tools available. Jetpack now includes a Site Management feature which has many of the useful features the more established services such as WP Remote and ManageWP offer. From one interface you can get an overall feel for the status of your websites and remotely install updates.

The threat from premium themes

WordPress itself has a strong security track record and as outlined in The WordPress Security White Paper, has a dedicated team of professionals responsible for ensuring vulnerabilities are dealt with in a structured and efficient way.

An issue I’ve seen causing pain recently is premium WordPress themes which come bundled with plugins. The idea is to provide additional functionality and value to the end user. However, as the theme author is the licence holder for the bundled plugin, it is their responsibility to update and distribute the patched files. As the site owner, you might not even be aware you’re running out-of-date, exploitable code.

Adding any third-party code to your WordPress installation increases the potential for introducing vulnerabilities. You should source your themes/plugins from the official repositories or from reputable developers who provide a clear update process.

How to avoid Google’s slow label – benchmarking

Processed with VSCOcam with c1 preset
This is a post written for the iWeb blog taking a look at a number of website benchmarking tools and services. Useful for pinpointing performance issues which can be improved upon.

For a long time Google have advised the web community that site speed is taken into account as a ranking factor. The move to displaying a publicly visible “slow” label may be the push site owners need to take action…

How to avoid Google’s slow label – benchmarking

Can you point me in the right direction?

Directions confusion
I provide web development and associated services to a small number of clients I’ve picked up over the years. This post is based on my humble experience freelancing and is aimed at those who, like me, are providing a service on a small scale.

Every so often I receive a question from a past client. I try to get back quickly and generally, I don’t mind as it feels good answering little questions and helping people. But those quick email exchanges add up and without an ongoing agreement, it’s a cost that I (and I imagine others) absorb because often those questions lead to billable work.

This lead to an interesting situation recently where I received a question worded with a subtle difference:

“Can you point me in the right direction?”

Many clients don’t understand the troubleshooting process that web developers and IT folk undergo in order to determine the nature of a problem. I imagine this isn’t unique to this industry. There’s value in knowing where to look and how to resolve a problem.

In many cases, it’s the troubleshooting process that accounts for the majority of time spent resolving an issue. Sometimes, the solution comes in the form of a simple flip of a switch, ticking a checkbox that’s buried deep within a settings interface. It might take an hour to find it, but it’s there.

Website owners should plan on paying a monthly maintenance fee to cover the costs associated with troubleshooting, updating and problem resolution. Unfortunately, this is easier to conclude with hindsight. My younger self wasn’t aware that these simple content sites might stick around for five, even ten or more years.

The takeaway? Make it a point to charge your clients for ongoing maintenance. I suggest discussing maintenance early on when you take on a new client. Bundle basic support along with CMS updates and regular backup. Then you can cover those quick questions which would otherwise be covered out of pocket.

Older Posts