Category Archives: Business

Thoughts on Open Source Hardware

A Few Positives

Customization

How many times have you run into a product thats 90% there. It may be an environmental chamber, a piece of test gear, or even a production tool. That remaining 10% can be a real annoyance at times. With open source, customers can have a product modified to get that last 10% solved… with closed source, often times pretty weird hacks are necessary as nothing else come close. I’ve seen production equipment hacked to death at times in order to make it do something reliably. Had prints been available, a third party might have been able to step in, or perhaps even the customer themselves could  make a minor modification to a less than obvious function, and be right back in business for less cost, and tons less aggravation.

Orphanization/EOL

The product life cycle can be considered sort of an inverted bathtub curve. In the beginning volumes are low, and unexpected challenges are often pretty rampant. In the middle, the product is rock solid, volumes are up, and costs are down. As a product reaches its end of life, it likely is no longer cost effective for a manufacturer to produce anymore. It may be due to production equipment wearing out, or a lack of institutional knowledge so support said product, or even individual components reaching end of life status. The end result of course is that a product is no longer made, and if you see an ongoing need, you may need to capture a last time buy and put spares in storage, or even search out used ones on ebay. Granted in a majority of cases, on going need ends up to be a non-issue. Most Ink jet printers for example have a finite life, and new models come out every year or two. On the other hand, other products may fall into a niche type industry. For example, some Epson printers are used for cake decorating, ie food grade printable inks… and if Epson were to EOL a printer line without a replacement, a whole industry of food grade printing could be affected. Granted, a printer would be a bear to open source due to its complexity, but the idea of EOL issues affecting more than just a single product is similar. With open source, one is no longer locked into proprietary formats, or the whims of the marketing guys of a sole manufacturer. (Obviously there is good and bad about such a concept… marketing guys like to be sole source and proprietary as that’s where the maximum revenue lies… and it may be the price targets in the open source arena can never compete with closed source due to limited volumes and investment opportunities). Either way, open source reduces some of the risk of EOL and orphanization issues that commonly occur.

Funding

Occasionally potential clients will want a project designed, but lack the financial resources to do so. One workaround for this situation is to fund an existing open source project, where upon I can provide customization services at much less cost than a full blown effort. Another possibility is to rally a number of contributors and build a related open source project, such that only modification is needed, rather than a full blown development effort. Granted there is an IP risk in doing so, but in reality, the largest risk in new product development is marketing, followed by a lack of funding to complete a project. IP risk, while very real, is much less of an issue than the marketing or funding aspects of failures. Open source is one possible way to work around funding shortfalls, and because of lower time commitments, may enable one to get customers involved earlier than later, and thus minimize marketing risk as well.

Time to Market/Risk Mitigation

Time to market is often times a critical factor in new product development. It may be an issue with a market window, ie seasonal, or trade related, or it may be an adjunct product that needs to be available concurrently with another product. Being open source designs most likely have a solid framework, its no longer necessary to reinvent all the wheels. It may well turn out that only incremental changes and/or cosmetic changes are needed, and thus trimming months or in some cases years off the development cycle.

A Few Major Concerns

Business Models

Existing business models built on loss leaders based upon proprietary design/integration wont work. Ie, sell the printer or game console at cost or at a loss, and make it up on the consumables.

Service and support are anathema to most existing business models, where as they are the life blood of open source revenue streams. Of course, there is the aspect of whether customers will pay for said service and support.

Economy of scale

The economy of scale may not be there to meet the customers pricing demands. Ie, when a single manufacturer tools up to build 100K units, there is the potential for significant cost savings, in contrast with 100 manufacturers each building 1000 units a year.

Investors

Investors may be wary of giving away the farm, ie the huge growth possible in a narrow channel is distributed across many. It will require a different approach.

Open Source Project Verification and Support

I’m a firm believer in open source software as well as hardware, yet, I see a real need for qualification of the projects, especially as it concerns hardware. There are just too many half complete open source projects out there, or worse, 3d rendered vaporware that looks so good, its very difficult to tell if its real or not.

Bad Economies Spurring Innovation? Accounting is key

I came across this blog post, and it made a lot of sense….

Lowering the water level: Do bad economies spur innovation? – Venture Hacks .

But, the problem is getting there, and I think accounting procedures for many businesses are likely a key to successful innovation, or the potential to go under in a huge way.

In good economic times, its easy to play accounting games and shift expenses from a pet project to a mission critical area. Ie, the new whizbang has tons of overhead, so the solution is to shift the accounting for that overhead to existing cost centers where it likely will remain hidden. Then multiply this by tons of pet projects, and all of a sudden, rather than a pet project having real costs associated with it… it seems a no brainer. Thats fine, until the cost centers end up bloated, and prime targets for budget reductions. The end result is, many core functions end up taking a hit, all the while the pet project looks good, at least for a while.

As budgets continue to shrink, the core function cuts will go too far,
and that will hopefully force a restructuring of accounting games,
such that the costs for pet projects become much more accurate.

Slashing key infrastructure only goes so far, before an entity can no
longer support its existing customers, and ends up going under.
Hopefully the downturn will foster more accurate accounting in time to put real numbers behind ALL functions. Not numbers good enough to continue funding pet projects for the next quarter, all the while
letting core functionality go south as all too often happens in large organizations.

Yes, I know its odd for the tech guy to put accounting on a pedestal, but cash flow and its proper allocation becomes really critical in a downturn… and if it uncovers inefficiencies and bad allocations of resources, it gets every one on the road to recovery and innovation a ton faster, as contrasted with riding the fake numbers as the ship goes down.

Prototype Qualification and Alpha and Beta Test Management

Based upon the products specification, we will develop a prototype qualification plan. This plan will include provisions for Alpha and Beta testing of the prototypes, prior to entering the next stage which is manufacturing preparation. We have access to labs all across the US, with a multitude of specialities ranging from product safety, environmental, FCC, and EMC testing. Our experience has been that even Alpha prototypes should go through a minimum series of test before being released to highly qualified end users for testing. Time and money spent in the lab can save many thousands in the field. This is even more critical for Beta test units, in that potential customers may be involved in the Beta stage. One day in the EMC lab can save numerous flights and field service calls to say nothing of saving face in front of ones Beta testers. The key however, is a well written test plan and qualification documents to try and catch as many potential failure modes in the lab, rather than at the Alpha and Beta test sites.

There is a tendency to want to sell Alpha and Beta units. We do not condone such practices, as such products are not production ready, have not been thoroughly tested on production gear, and just by their nature, may require another interation or two to meet the design specification. As such, the final stages of manufacturing preparation, and product release should be completed, before anything other than pre-release intent to purchase commitments are made.

By the same token, it can be advisable to require some financial commitment on the part of Alpha and Beta testers, such that they take the testing process seriously. I recommend taking deposits as a requirement for Alpha and Beta testing, such that the deposit will be refunded upon the completion of the test, and the return of the Alpha and Beta units.

Google Docs, a cool collaboration tool

Google Docs is super cool. Currently, I am working with 5 different collaborators from all around the world, on a number of different projects. Google docs provides a framework for revision tracking, world wide access, and the ability for multiple users to work on a document concurrently.

Not only is a Word type format available, but also a spreadsheet. Both seem to work pretty flawlessly, and a little window pops up to let you know more than one person is editing a document at once.

Considering the magnitude of some of our projects, google docs is truely a life saver. I am totally awed. Now, if only they could add mechanical and electronics CAE tools. 😀
Google Docs, a cool collaboration tool · 2007/03/26 20:45

Leadership Analysis

I always seems to find the challenges, or as open desktop mechanic states, doing things just this side of impossible. Well, now the fun begins.

I get to analyze an organization for operational and leadership effectiveness. Granted, years back I did industrial consulting on the tech side, and being exposed to a multitude of businesses, does give me a unique view. Its often said, that tech problems are easy, the tough part is how to appropriately manage them.

Thus, its time to get the books out, do some digging, and refresh my mind of how to go about this. Initially, I thought of 360 degree feedback, as that was sort of the buzzword years ago. Yet, finding appropriate forms, and the ability to interpret such data, when one is not totally up to speed, can give less than valid results.

As such, I’m going the old and simple way. Observation and reporting as a third party outsider. Since I won’t be privey to all the details, its a bit harder than if I were an insider. Yet, the lack of bias, is probably what this organization really wants, as contrasted with a rose colored glasses, or a half empty approach.

Thus, its leadership checklist time.