Solstice Software » Software

Website ownership in layman’s terms

john.ensign — Sat, 13 Mar 2010 03:59:01 +0000

Do you really own your website? This is a good question, and it isn’t really near as black and white as one would imagine. It’s sometimes helpful to have an example to speak of, so we’ll talk about Joe, who just had a website built for him by the fictitious Acme Web Company. When Acme gets to the point of actually building the website for Joe, they will use many processes, tools and code libraries. These assets may have been created by themselves, or they are acquired from other companies.

So, if its Joe’s website, but Acme used its own tools, in-house utilities, code, or systems to produce it, who actually owns it? Lets look at things from both Joe’s and Acme’s perspectives.

Joe’s Assertion: Joe believes that he owns the rights to his website, all of the back-end code, HTML, content, all of it! Joe paid good money and in all senses of the word “buy”, believes that he is the rightful owner. Fair enough, this seems sane to Joe and probably most people who pay a lot of money for a website.

Acme’s Assertion: They provided a bid to Joe knowing that they would be able to leverage their internal systems, code libraries, and processes to make Joe’s website a reality, and have no intention of giving ownership of any existing assets they brought to the table to Joe beyond fulfilling their contractual obligation to fulfill the functional and design requirements for his site. This seems sane too, it would be like asking the plumber to leave his toolbox, tools, and van after he installed your new kitchen.

So who is right, who really owns the site, and why would it even matter?

Just about every web shop on the planet leverages modern tools which give themselves, and the clients a competitive advantage. These tools are sometimes in-house creations, though more often, they are tools which are written by other people and either purchased by or licensed to the web shop. Examples of these tools are not trivial, they include Content Management Systems, Javascript libraries ( all those fancy menus, forms, and web widgets you see ) and a slew of tools used for security, database interactions, and well… you get the picture. Ownership per se, is almost always an issue which revolves around licensing.

So what part does licensing play in all this, just tell us if it is Joe’s website or not and why should we care?

Imagine for a second that Joe wants to move his website to another hosting provider. Acme says “OK Joe, were sad to see you leave but here is your site in a nice zip file”. Joe and his new hosting company setup his website, but Joe realizes that it doesn’t function anymore. Joe is beside himself and calls up Acme demanding the “right” version, the “working” version of his website. Acme responds with “we did, we didn’t sell you ownership of many of the tools your site uses, we sold you a license to use them while you were with us”. This is a bad place to be, because the reality is that the web shop really didn’t clarify in “human” terms, what it meant to “own” the website. Joe is of course none too happy and is now faced with paying someone else to make his site work again.

So little code is actually written from scratch these days web wise, that its almost a foregone conclusion that the buyer of a website does not actually own a full functional version of their website. Granted, there are exceptions! So are we all doomed or what, a little light at the end of the tunnel please!

The answer here is to be an informed buyer and asking questions like:

Please tell me about the systems you use and any respective constraints or restrictions I might face if I buy my website from you and decide to move to another host later on?
Will my site still function if I choose another hosting provider other than you?
Are there any specific rights I am granted by the tools you might use? Reference the General Public License.
Tell me about any specific obligations you have to me with respect to the tools you use.
Will you indemnify me of claims if one of the authors of the tools you use comes after me because he saw that my site uses his new fancy web widget?
Can I sell copies of my new website to other people?
Can I sell subscriptions or sub-license my new web site to other people?

Any web shop worth their salt should be happy to discuss this with you and answer your questions. Many companies don’t want to talk about it, because they are afraid of their private code or systems getting into the hands of competitors, that it might kill the sale, or that god forbid the client actually becomes educated. Reputable web shops should be able to spell it out in clear terms to you, you deserve to know. This post is a rather cursory overview of the subject, but should be enough to get you going in the right direction if you have any interest in the topic.

Here is a list of the more common licenses that are attached to most everything you see on the web:

/John Ensign

Drupal Prototyping

Seth Brown — Thu, 11 Mar 2010 18:24:42 +0000

Most webshops worth their pixels engage in some form of pre-production on all projects. This is the planning phase. Building analogies are often used to describe the value of this stage of a project. ‘Would you break ground on a house without a blueprint?’ And it’s a fair point. Websites are complex collaborations between project managers, graphic designers, information architects, developers, QA specialists, account managers, and, of course, a client. In general, it’s a process requiring systematic diligence on the part of an experienced team. Traditionally, the blueprint consists of a combination of a site map, written specification documents, photoshop files, content (copy, photos, multimedia, etc.) and possibly even user interface prototypes. For software, the list of deliverables is even more onerous (vision & scope, use cases, functional requirements, non-functional requirements, wireframes, and, ultimately, an SRS). These deliverables form the basis of agreement between the client and the webshop as to what is to be produced. They also provide a comprehensive blueprint that an engineer should be able to follow without a lot of additional input. It’s a time-tested and reliable process that the haphazard ignore at their peril. Once the client signs off on these documents they form the groundwork for the contract to produce the actual website.

This form of pre-production is not without it’s flaws, however. In general, human beings are not particularly good at predicting the future whether its time-line expectations, design comps or functional prototypes. Marketing assistants are not always good at intuiting their boss’s aesthetic. The type of documents web companies and their engineers desire and assiduously produce–invitingly titled tomes such as ‘Functional Requirements v3.1′, ‘Technical Solution Definition’, ‘Service Level Agreement’–are given a cursory glance by the client and signed with all the careful attention one might afford the ‘License Agreement’ for their computer’s Operating System. Clients, in general, spend more of their energy responding to the photoshop documents, but these mock-ups too often overlook important user interface considerations and omit the back-end all together. In addition, they are expensive to produce.

So, while the traditional approach–the “blueprint”–described above gets the job done and trumps the alternative of no plan at all, there are often points of frustration.

The client is constantly trying to change the requirements, content and design after the blueprint is finished. ‘Let me get you that change order document,’ is not a happy-making response to this desire.
The pre-production process can be time-consuming, expensive, and frustrating to the client. ‘Is my site done yet?’ ‘Well…yeah…we haven’t actually started it, per se.’
People don’t read, especially when a document is outside their domain of knowledge. The client may sign off on the functional requirements and then express surprise when they find a precious feature lacking after the fact.
Photoshop documents aren’t working models and cannot be tested. Often the graphic designer’s solution is neither practical, functional, or the best from a usability standpoint.

So is there a better way? Sort of. It won’t work for all clients or projects, but we’ve found a dash of agile methodology combined with a good content management system like Drupal offers an interesting alternative. With the client’s participation and active involvement, it’s possible to take an iterative approach to starting a website project. Instead of producing blueprints, the project manager, information architect and client collaborate on a living breathing Drupal site to build out the information architecture and menus, prototype the content types (these are database objects with specific fields–for example…listings, testimonials, events, people), create sortable views of these content types, add page content and other assets like photos or virtual tours, comment back and forth, enable and test modules, and place persistent elements such as sidebar blocks, ads, etc. in their likely eventual locations. The nice part is that a content management system like Drupal is flexible, decisions can be easily reversed. Time spent on these endeavors results in measurable progress toward the final product. One of the primary differences in this method is that the graphic designer (assuming the basic brand is done) can stand aside for this part of the development. When it comes time for them to create the theme or design for the site, they will have a much more concrete picture to work from and it will be clear where their time and expertise is most needed.

But what about the blueprint, you say, what fool would break ground without one? A CMS, like Drupal, provides enough of a framework for building a site that many critical technology and functionality questions are effectively answered. Think of it as a bleeding-edge, environmentally-friendly, factory-made, stick-built modular home that lowers cost without affecting quality or sophistication. Tools, such as the combination of cck, views, panels and rules can get you 75% of the way toward creating a functioning web application without having to write unique modules from scratch.

There are challenges, of course, with this method, and it requires a certain type of client. It takes a client with both faith and imagination who’s willing to proceed on an hourly basis secure in the knowledge that the overall cost of the project will be lower, the timeline will be shorter and, at any moment, the iterative work-in-progress can go live. As the saying goes, the best kind of marketing is the kind that exists. (Websites, unlike print work, will never be either perfect or done.) The client must also be available and able to make decisions for their organization. The frequency of meetings increases, but the meetings are shorter, informal and more focused. In return for these concessions, the client enjoys the satisfaction of participating in an iterative process that unfolds before their eyes.

At Solstice Software, we believe both methods of pre-production are essential and it comes down to the nature of the client and the project as to which is best suited. If you’re interested in a more iterative, less formal approach to pre-production, call us at 970.618.5370 or do some further reading…

‘Getting Real‘ is a fantastic and highly readable manifesto by 37 Signals on the virtues of this style of web production
‘Death to Visio Site Maps ! How Clear Ink uses Drupal for Information Architecture, Prototyping, and Project Management,’ explores prototyping in the context of Drupal.