Skippy Records

I often rant about the current challenges of over-zealous copyright laws.  Andy Oram over at O'Reilly sums it up nicely in a lengthy post on the blog.  If you care about innovation--the future of creativity and individual contribution to invention, art or software development--it is worthwhile to take a few minutes to understand the legal and economic state we have gotten ourselves into by extending copyright at the urging of a few powerful copyright holders.

Posted by DrSkippy27 at 03:43 PM | Permalink | Comments (0)

Fifty thousand of my friends and I ran the 29th Bolder Boulder yesterday.  At the starting line and at every mile along the way, there were two blue lines on the ground about a foot wide running across the course.  And there was an incessant beeping (more like a continuous tone since I was in a fairly dense crowd) every time I crossed one of these lines.  This was the "detection" end of the a new system in which we all wore little plastic tags, zip-tied to our shoes in the hopes of getting precise timing for every section of the course.

It is Tuesday morning and the results don't seem to be available anywhere yet.  In fact, the Bolder-Boulder Web site is only occasionally accessible.  This reminded me of some customer service guidelines that can help relieve the load when something like this happens (as it always does):

1. Transparency--give your users up-to-the-minute information about what is going on. If you have 50,000 people hitting your web site multiple times in a matter of hours, you start to have additional load problems that you didn't have before the failure.  This slows the site, increased frustration and decreases satisfaction.  Instead, tell people what is going on, preferably with a temporary blog where additional traffic isn't going to multiply your problems on your main site.  Put prominent links to this timely information on a temporary, lightweight (minimal server load) homepage so your users get to the information they need to make a good web site use decision. Consider releasing the story in a way that a Google search will result in the information being communicated without users hitting your site.
2. Give an estimate date or time for the race results to be available.   Keep the projected date/time updated. Plan on, a huge traffic surge at this time and get the resources together to accommodate it in the meantime.
3. Syndicate.  Publish the content to some trusted partners to take the load off your site. Users want the information; getting it from your site is secondary.  You may have a business model around the traffic, but poor customer satisfaction may make any short term losses do to lost traffic irrelevant.
4. Run parallel systems.  Until you have verified that your system can handle the load, run the old system in parallel.  "If you can't run it on papers, you can't automate it" is a good rule for all business process modeling.  In this case, run the old and new system in parallel so you have a fallback.

All of these suggestions boil down to two aspects of responsibly made commitments:

• Clearly set expectations as the what?, when?, where how?
• Avoid denial! during a crisis, commit only to things that your organization can do (You can dream big on your own dime, not while you have customers lined up waiting for you basic services to be deliverred.)
  
• Competently meet or exceed expectations

Making responsible committments doesn't stop after the first glitch. In fact, that is just the time when excellent organizations get diligent about it.

Posted by DrSkippy27 at 11:17 AM | Permalink | Comments (0)

I posted earlier about the Silicon Flatirons session on “Re-examining Open Source & Community Development.”  During that session, I took some notes on organizational practices that may help as a commercial software development teams contribute to Open Source software projects and build commercial products from Open Source software.

Below are five guidelines discussed at the session: 

Guideline 0. Record every use of Open Source as it occurs.  Print paper copies of license agreements.  Be sure to keep the copy of the license under which you started using the Open Source applications or components as licenses may change over time.

Guideline 1. Decide how and when your company will provide indemnity and warranty for Open Source software.  Evaluate the risks your are assuming as you may have little or no upstream indemnification or liability protection from the Open Sources licenses you have agreed to. Articulate this policy to your customers and users of your software.

Guideline 2. During a sale or major funding event for the company, the question about Open Source software use will come up.  Because there is no purchase record for Open Source software, you should assemble your documentation form engineering notebooks, filed Open Source license agreements (see Guideline 0) etc. as you prepare for due diligence.

Guideline 3. Your strategy for complying with Open Source licenses is to cooperate with the community as much as it is to figure out the exact meaning of each agreement and come into technical compliance.  As much as staying out of court, you are trying to stay off Slashdot (www.slashdot.org) or get the negative attention of the Free Software Foundation.

Guideline 4. If your company chooses to build a core product using community development and Open Source licensing, articulate your code ownership policy clearly to every contributing developer.  If you plan to retain ownership of the code, create the appropriate Ownership Assignment Agreement, have each developer sign it and keep them on file.

Posted by DrSkippy27 at 09:54 AM | Permalink | Comments (0)

This question was raised to the panel at the Silicon Flatirons seminar "Re-Examining Open Source and Community Development" on March 5, 2007. I think this is an interesting question and I thought it would be fun to try to answer this question for myself.

I think Open Source as a way to organize resources for development will be more broadly understood and more explicitly leveraged to solve problems like building software.

I am enthusiastic about building software because I see it as one of the most direct tools for extending and amplifying human intention.  It is an enabler of an increasing scope of desires for learning, analyzing, organizing, filtering, entertaining, communicating, and connecting.  As an intention-enabling tool software must continually adapt and evolve with the sophistication and sphere of focus of those doing the intending.

The most effective solutions to these problems evolve from cooperating groups of user-developers. This is one of the key differences between well-run, large-scale commercial software projects and Open Source projects--the users are the developers in the latter case, while the developers are hired professionals in the former.

This "user-" difference has many implications for the time it takes software functionality changes to drive innovative changes in the behavior of people using the software, which in turn results in ideas for new software functionality. And around it goes.

The "-developer" difference will become more significant than it is now.  Tools will improve in both power and ease of use, enabling non-nerds to develop intention-enablers (software) that only nerds could develop in the past.

I anticipate that intention enablers, including software, but also including modes of cooperation, spiritual practices, models of rapid value creation in conversations, etc. become much more powerful in the next 10 years. So do the tools and, therefore, so does Open Source development.  Of necessity, licensing of the intellectual property that supports the evolving modes of creation and patterns of use plays a larger role as well.

Posted by DrSkippy27 at 11:39 AM | Permalink | Comments (0)

Design your product pricing strategy after you have a thorough understanding of the customer's traditional accounting practices.  When they license your software or contract for your services, they will evaluate the financial success of the relationship in the context of these practices. If your pricing strategy is out of step with your customer's operational cost accounting, project valuation and capital cost accounting practices, an otherwise attractive business deal might not look attractive at all.

The answers depend on the target industry.  Manufacturing has different traditions than Web 2.0 startups, publishing is different than restaurants. Some companies evaluate software solutions purchases by looking at total costs of owning a solution over the expected payback period.  Some focus more attention on maintenance or contributions to COGS. Even those that look at total expenditures may not factor in the costs of internal resources, or may account for them in different ways.

Learn how the important target customers in the industry evaluate project success. Learn which accounting bucket maintenance charges go to and what part of the cost of your software or services will by included in COGS.

A company I recently worked with priced their ASP software services by the slice. Each slice has a wholesale cost of $2-3 to the customers, who in turn resold these services in bundles at $5-$100.  There are no annual maintenance fees for the use of the software. Further, Company's pricing includes many basic integration services, so there were very few professional services fees.

A competitor rapidly gained traction when they presented a pricing plan with a by-the-slice component at about 25% of Company's fees. Obviously, the customers thought this was great because it reduced COGS and dropped this savings directly to the bottom line (at least for the team managing this product's sales).  In this organization, the IT budget was used for operational expenses such as integrations and periodic maintenance. No one bothered to calculate the total cost of each solution.

From a total cost perspective, Competitor's pricing wasn't nearly a clear win.  Company's price included basic integrations to 3rd-party products and services; Competitor charged extra for these.  Because Company's revenues depended on customer performance, they were eager to provide free training at the call center and in the field. Competitor charged extra for these services.  Being an ASP and wanting to keep the pricing simple, Company didn't charge periodic maintenance fees; Competitor did.

Because total cost wasn't part of the industry standard for project evaluation, Competitor won key customers. Company failed to design a pricing package the fit that customer's traditional accounting practices.

Posted by DrSkippy27 at 03:05 PM | Permalink | Comments (0)