Recently, we helped one of our departments (who shall remain nameless) identify an external vendor to help them with a website design. We were in the middle of an active development cycle and didn’t have time to do the project for them. And so we were acting in the capacity of a consultant, whose responsibility was to find an appropriate vendor and get the conversation going. We did the research, asked some others about the reputation of the vendor and then, being satisfied, handed off our customer to the vendor.
Over the intervening weeks, we kept an occasional eye on the process, but didn’t insert ourselves into the conversation. Meetings between our department and the vendor appeared to be going well. The day to deliver the product came. We scheduled a hand-off meeting with the vendor, our department and IT staff. The design was delivered as a WordPress theme.
Several issues were immediately apparent. Although the vendor was paid a fairly high fee to develop a “custom” design, it was obvious from the code that what they had really done was take an existing commercial theme and make some modifications. While this practice is not uncommon and is within the license of most commercial themes, the vendor had taken steps to hide the fact that they had done this. They had removed the license from the theme and didn’t divulge the fact. They also distributed the theme along with a (large) number of plugins, some of which were commercial. When asked about the licensing, they didn’t really have an answer, but eventually sent us license codes to show they had bought the plugins – overall, very unprofessional.
Another issue was that the theme was not designed as a “child theme.” This is a standard practice in CMS design that separates modifications to a commercial theme into a separate set of files. This makes applying updates to the theme much easier because the base theme can be upgraded while maintaining all of the customizations in the child theme. Since the vendor made changes to the base theme, it was difficult to tell what changes were made. Updating the base commercial theme then became impossible. When our department confronted the vendor with these issues, their response was defensive (of course) and that they wanted us to come back to them for maintenance in the future (no doubt as with a hefty fee attached!). We tracked down the theme and version, but when we approached the original commercial theme vendor, they were reticent to give us the older version theme files.
But the pièce de résistance was that they had given us files that had been compromised. After deploying the files, we were informed by ITRM that some inappropriate male potency search links were reported in the site. After investigating this, we confirmed that the source of the problem was one of the plugins they had “sold” us. It apparently had been compromised on their development servers and they had passed it on to us. We were left holding the bag, and in the bag was a big mess.
What went wrong?
While much of the blame can be laid at the feet of the vendor, IT must take some of it as well. We were not following the project as closely as we should vis a vis, we should’ve attended the meetings and monitored their progress. We should’ve written into the specifications that the vendor would deliver a child theme. We should’ve specified that any commercial themes or plugins be disclosed and licensed, and that licenses should be transferred to us.
Overall, we learned some valuable lessons. We should closely monitor any external vendors that serve our customers. Had we been following the process more closely, we most likely would’ve been able to forestall one or more of the issues we had.
