It all comes down to this.

When I put this depiction in to word, I would say it as “Industry Standards > Organization > Team > Personal > No Standards“.

It is that simple. Everyone has standards. However, some standards are more important than others. When developing your own standards you should consider those standards that are greater than you first. So your standards should extend those standards that are defined above your position.

As an example, consider a Java developer working for a major US Bank.

Industry Standards

Most developers have two industry-level standards to consider. First, the language that you are developing in. Our example developer is a java developer. Sun publishes a Code Conventions for the Java Programming Language. This document provides a broad range of guidelines for various facets of the language. Next, consider the financial sector’s software development guidelines. You may or may not be able to find such guidelines, and when you do they will probably not be specific to your language. I’d imagine there are rules for how many decimal places into dollar amounts you should keep, and how to store currency types are all documented somewhere.

Organization Standards

Now that you’ve adopted the industry’s standards, look to your organization. You might be a member of a huge multinational corporation, or a small 2 developer shop. Whenever the industry does not cover a specfic aspect of your software, your organization has the opportunity to define standards. These standards may be how to name your SVN repositories, or how many characters long your variables must be. These are things not covered by, for example, the Sun Code Conventions for the Java Programming Language.

Team Standards

Your organizaiton may not care about some aspects of their software, but your project manager or project team may still have rules that they follow. These are standards that you and the other developers on your software project or team follow.

Personal Standards

Finally, you have a situation where there is no defined standard anywhere. So you get to decide how you will perform some task or format some code. Whatever you decide to do, think it though, and do the same thing the same way next time. Personal standards are important weather you are working in the office or working at home on your own project. You are the same developer on both projects. Your code should reflect that fact.

No Standards

Why would you code in one style in the office only to drive home and code differently on your home project. This is chaotic. This can prevent you from effectivly transfering experience from your office projects to your home projects.

Documentation

De Facto standards are those that tend to happen not because they are law, but more out of practice. There are no such things as de facto standards. Standards should be and must be documented and developers must know where to find this documentaiton in order for the standards to be effective. This documentation should be easy to find, easy to access, and even easy to update.

It is sometimes hard to define a standard that covers all situations. When developing your doucmentaiton, you might consider defining the typicial situations that those standards fit into. These leaves the hands of your developers untied so that they can focus on producing high quality software and not be bogged down by unneccesary blanket rules.

Wikis are great tools for maintaining software development standards for a small organizaiton or development team. They allow team members to update the documentation as new standards are developed and as new situations are encourntered. Other developers can usually subscribe to the wiki to be notified of changes so that everyone is always up to date.

Why are standards important?

Following standards are not about making software development harder or more tedious. They are about making development easier and cheaper. InfoQ recently posted an article called Better Best Practices which listed a few great reasons for developing best practices, but it turns out the same reasons for developing best practices hold true for following standards too. Their list is titled “The motivation for Best Practices” but I could easily title this list “The motivation for following Standards”:

They ensure consistency. We are introducing [insert initiative] and we want to ensure that everyone goes about it the same way. We don’t want to abandon people without offering them any direction and the alternative would be chaos.

They support learning. We are trying to get everyone up to speed on this new approach with the minimum of fuss, and having a standard set of well-structured material means people can see exactly what they have to do, and ideally how well they are adapting.

They help limit (potential) impact or damage. (Now we are starting to see their true colours.) In any organisation there’s a bell curve of people’s abilities, and we know that a small but significant number of people will be at the wrong end of it. Implementing this program badly could leave us exposed to significant financial or legal business risks, so we’re going to need very clearly defined practices to protect ourselves. They are called Best Practices because they are tried and tested so I can be reasonably sure they are going to work.

They help to build a more mobile and flexible workforce. In these fast-moving times, projects can materialise or be cancelled almost overnight. People move between project teams, projects move between offices, countries or timezones. With all our people trained up to use the same Best Practices we - and they - have many more options in terms of career mobility. We call it “commoditising resources”.

They allow us to enforce control. In a large, hierarchical organisation, this is the real crux of the matter. A division manager or vice president may well be responsible for thousands of people. The only way to provide accountability on that scale is to have a system of clearly-defined and strongly-enforced Best Practices.

What do you think? Are standards a waste of time? Or do they create time? What good or bad experiences have you had with some enforcer pushing standards down your throat. Were those enforcers in the right or the wrong?

Introduction

The aim of this post is to explain how open sourcing a proprietary tool under a duel license can be more profitable than a solely proprietary venture. With such a license you could generate more revenue and share your code and software with the world.

Dual licensing is a strategy that combines open source distribution with proprietary licensing. I don’t want to spend too much time explaining duel licensing and would rather point out its benefits and how it makes money. But if you don’t know what duel licensing is, wikipedia describes it as

In this model, one option is a proprietary software license, which allows the possibility of creating proprietary applications derived from it, while the other license is a copyleft free software/open-source license, thus requiring any derived work to be released under the same license. The copyright holder of the software then typically gives away the free/open source version of the software at no cost, and profits by selling licenses to commercial operations looking to incorporate the software into their own business.

So, in order to use the free half of this duel license, the using organization would have to contribute back anything they develop using your product. This means their proprietary trade secrets are potentially being made available to the public. Many organizations would rather pay a small fee to protect their competitive advantage.

So lets review some of the ways that duel licensing grants an advantage to business that release their products under two or more conditions.

Low Cost Distribution

Open source software depends on the Internet for distribution. The internet is cheap, ubiquitous throughout the world, and fast. There is no need to mail a product to the other side of the world, there is no packaging, Usually the customer uses 100% of their own efforts to get the software. That is to say, the find your site, they download it, and they install it. It doesn’t get any cheaper than that.

Product Marketing

First, your product is potentially free. That’s some awesome marketing. So right away you have eyes looking at your tool so you’re way ahead of your proprietary competition. You’ve got the Internet which is almost free to promote your software tool on. And with a good product, you’re going to have advocates around the internet talking up your tool.

High Margin

Duel licensing provides a means for producing a very high margin for your product. With a service based offering, in order to offer more services, you need to spend more money - for tools, personnel, time. Duel licensed software requires no additional resources, just enough time to generate and mail out a new license. Once the code is created and ready for public consumption its all profit from there.

Market Entrance

You may be able to capture users that you never would have had a chance with if they have not found your product to be free, and then determined that they needed to change it, and thus buy a a license to protect their proprietary information.

Learn More

I learned all about duel licensing open source products from a great book called Open Sources 2.0. From amazon:

“Open Sources 2.0″ is a collection of insightful and thought-provoking essays from today’s technology leaders that continues painting the evolutionary picture that developed in the 1999 book “Open Sources: Voices from the Revolution” .

These essays are very well written, cover a very broad range of topics, and is written by open source contributors that we have all grown to know and love. Buy the book and check out Chapter 5:Duel Licensing.

I try to keep an eye on what Internet users are saying about Architecture Rules. I checked del.icio.us for architecture rules. Its bookmarked by 60 people, which is pretty cool.

I read one description which concerned me. Chris suggested in his description that architecture rules as “way to ‘test architecture’, although it seems to be limited to detecting cyclic package dependencies”. Whoa, hold on. That’s not what we are about. Detecting cyclical dependencies is something that we can do, because we wrap JDepend, but the whole point of the project is to assert that the Rules that you have defined are not violated.

So, I tracked down Chris’s email address, which I found in his resume, which I found on his site. I emailed him.

I started by apologizing for the unsolicited email. Next I explained that I found his comment delicious, I reiterated his comment to him, then briefly explained and showed (with XML) how architecture rules was about asserting architecture through the definition of rules. I sent off the email assuming that Chris probably wouldn’t read it, and certainly wouldn’t respond favorably. Fortunately, I underestimated Chris.

Chris wrote back to me and thanked me for taking the time to write to him. He also pointed out that it is “always a good sign to me when an open-source project is interested in what people are saying about it.”

I just wanted to share this experience. I have no great analysis of it yet. I hope that it might encourage you to think about reaching out to your user base weather they be paying customers or users of your open source tool.  After all, thats why we write the code, right? To satisfy the end users, to make their jobs easier, or to change the way that people do business.