Jochen's posterous

"when work is slow - discount the price, better than nothing" - nothing could be further from the truth

Many years back I worked closely with a web design company and I had a
conversation about how to write quotes with their business development
manager. He said: "When we have work on, we quote based on our normal
rates. But when we have nothing on, we reduce our prices - after all
its better than nothing." Nothing could be further from the truth
(sorry D.)

When we offer clients a discounted quote, one or more of the following
things happen:

- we do a certain amount of work for free.
- quite a bit worse, instead of planning the project normally and then
discounting it, we probably throw in some things that are a bit
unplanned and will bite us later in the project when they mushroom
into bigger complexity, maybe even with some other paid extensions to
the project
- when the project is finished, the client has an unrealistic
expectation of what maintenance and changes will cost and there will
be friction.
- at worst, we will underbid a competitor, that may be much more
suitable to service this client.

Many of these things show that we do not only ourselves, but also the
client a disservice.

Here are a 4 lines of defence that can be used instead of discounting the quote

- Always keep the pipeline full and always be marketing
- build the network to call upon, before it is needed to fill the pipeline
- forgo the revenue, instead of making a loss on it.
- supplement the business income from somewhere else


Kind Regards,

Jochen Daum

"There is no shortcut to anywhere worth going" - Beverly Sills

Automatem Ltd
Phone: 09 630 3425
Mobile: 021 567 853
Email: jd@automatem.co.nz
Website: www.automatem.co.nz
Skype: jochendaum
http://nz.linkedin.com/in/automatem
http://twitter.com/automatem

Why purchasing open source licenced is the right way for VC and self funded startups

A topic that we discuss with potential clients regularly is licencing of software for (usually web based) startups. This is an important question, as a startup would like to ascertain at at early point what will happen when they want to sell their company on in the future. Another concern is also the software company competing or helping someone compete with the startup by "re-using" the software.

Some assumptions

For the discussion here I'm assuming that:
- the startup is Venture Capital or self funded, essentially paying a software company to develop software - software is not provided as "sweat equity"
- the software system required is a custom development, ie it is reasonably complex

How open source licencing works

Open source licencing of custom written software works through the following steps:

1) The developer is accustomed to using or sources a set of existing software code, which is in turn licensed under open source licences. Such software usually has been produced by dozens to thousands of people.

While it is not necessary for the developer to re-use software this is accepted as best practice, because:
- such software is typically security-audited by thousands of users
- allows for re-use of typically used program code and programming patterns
- exposes the developer to other people's programming techniques

2) The developer issues the same licence to the client and "distributes" the software including source code.

The client now has a licence to use the software as they see fit. Specifically in comparison to common proprietary software (say MS Word), the client can:
- make copies of the software as necessary
- has no time limit or geographical limit to use the software
- can engage another developer or in-house staff to modify the software.

3) The client does .... nothing

There is no further step, however we often receive an objection at this point in that many people assume their software is now "out there", free to be downloaded and used in competition to them.
Of course it is not.

While developers of mass-used open source software would of course want their software to be available to anyone to achieve market penetration, a purchaser of custom written software wants exactly the opposite - they want the software to go absolutely nowhere else.

In summary, there is no "forced publishing" of open source software and licences take place when software is distributed. 
A side effect of this is that you possibly don't have a licence to the software, because it hasn't been distributed to you. So, go, get a backup of the software.

4) At time of sale of the business...

.. the new owner acquires the licence. Simple as that.

To explain why open source licencing is good for the startup, lets look at their options to source their software system.

Employee

Of course you could hire an employee to have the software system produced. However pitfalls are:
- Many startups in New Zealand don't have the cash to hire an employee for long enough and after development don't have the scale to hold on to that employee
- Startups are not experienced in hiring a software developer and cannot provide an interesting environment for such a person
- For the employee this is a higher risk situation - an unknown employer, possibly lower pay than in other positions. Therefore it is likely that only low to medium skilled employees are attracted to such positions

"Sweat equity"

This can be seen as an extreme case of an employee. While of course sweat equity is typically cheaper in the short run, it is likely either going to attract
- unexperienced employees (technically or professionally) who accept a very small equity stake (ie no control whatsoever) or
- very experiences employees, who will however want to have a significant stake in the business

Closed source or proprietary licence vendor

A closed source/proprietary licence vendor alleviates the issues with employees, however with it comes the risks of having serious licence restrictions that may limit the ability of the startup to scale or operate. Issues include:
- licence costs that grow with amount of use of the software (per seat, per site, per processor)
- vendor controls technology platform, effectively this may cause a "rewrite" every 3-5 years because of the vendors vendor doing the same
- licence can be revoked at any time or is otherwise time limited and needs renewal

Open source vendor

Buying your startup software open source has all of the above benefits: full control (in time, code and supplier dimensions), while using best practice software development.

A further point is that open source software is currently in fashion. This may seem an irrational point, however think about how things in fashion attract the best employees and lead therefore to better software for the customer

Common objections

Ownership

Clients of ask us if they "own" the software. Owning software is a legal term and we have to say no to this. If someone else owned software that we have produced it would mean that they can stop us from using it ourselves. The only way to achieve software ownership would be to hire an employee or acquire the development company.

Of course from a legal perspective "ownership" is the most desirable option, which is why you would receive advice from most lawyers to "own" your custom developed software. However the reality is that no vendor could give you ownership of the software. They would either have to erase their mind and do it all again from scratch for the next client (and produce sub standard quality software each time) or get themselves into a legal quagmire.

Warranty

Many open source licences have "No Warranty" clauses that are printed in all caps and stand out. These are put in there, so that free of charge downloaders do not claim warranty from the supplier of the software.
Of course in the case of a custom development you would get a software development agreement in place to cover warranty, confidentiality and many other questions.

From a developers perspective, "warranty" can be quite a topic to laugh about. None of the well known proprietary software vendors gives any warranty to speak of - what you get is evasive support that tries to suggest alternatives, workaround or defers you to a "possible solution" in the next software version. in comparison, most larger open source development communities (mailing lists, online forums and social media) will answer the developers technical questions usually within minutes - free of charge.

Competition

Can the software vendor simply go out and sell it to another party.

From a licencing perspective, yes they can. However (non-) competition is a really a different issue that can be contractually arranged between the client and vendor. It is simply a commercial issue around: which markets does the client need to be protected in against what competition? Which markets is the vendor really going to sell this software system to?

Another perspective on this comes from when you consider what "custom development" means. Is there really going to be another client with exactly the same business model that wants to buy this (needing to know all other business secrets from the first client!), so the software can be used as-is? It is much more likely that the 2nd business needs some quite different software.

The issue is rather more about confidentiality and what information a vendor may inadvertently disclose about the competitor.

"Open source infects proprietary software we or our future buyer use"

This is a valid concern, if the software is licensed under GPL licence. The GPL licence is probably also the most widely known open source licence. However a review of common open source frameworks on Wikipedia shows that an overwhelming majority of such frameworks are licenced under MIT, BSD or Apache licence, none of which are "copyleft" licences. This means that they can be mixed with proprietary software code without affecting licencing of the resulting combination.
It is highly likely that a software developer is going to use such a framework - rather you should not engage with one that doesn't, as you won't get all the benefits of using open source software.

Summary

Purchasing custom developed software with open source licencing is a very good solution that eliminates common issues of contention between the purchaser and the vendor.

As a final though, the developer "giving away" most control over the software shows a deeper reality about modern custom software development:
The value of the software is not really in the software code. Most functions required, for example a user login have accepted best practice solutions. There is no value in owning another copy written from scratch, every developer knows how to do this correctly. The real value is actually in the delivery of software that is flexible, future-proof and where changes can be managed over time.

Jochen Daum

Chief Automation Officer
Automatem Ltd

How to have good password security (for Everyone, Business Owners and Web Developers)

In recent times, breaches to passwords and user/ customer databases have been widely publicised. The breach to Gawker media's password database, AA's recently hacked survey database as well as the astonishing 30 Million passwords stolen from RockYou are examples. In the Gawker and RockYou examples the stolen passwords have also been publicised, showing that a surprisingly high amount of users choose a very small amount of weak passwords. 

All these password breaches could have been averted by better security practices at the web sites in question and the impact could have been alleviated to nearly none by the users choosing the passwords. In my professional opinion *both* needs to happen, rather than one side waiting for the other to fix the problem. Neither party to this problem will be able to "fix" the problem in any case fully, as the problem is of a educational nature.

Here is what we tell clients, their employees, everyone else and web developers (that want to listen)

How to choose safe passwords

Low to medium security

For nearly all cases of low to medium security requirements the safest way to choose a password is to have it randomly created and store it in your browser. There is a myriad of tools available to generate passwords, what you should look out for is that the password is at least 8 characters long and contains at least 2 number and 1 special character.
It may seem counter intuitive to "write down" your password in your browser, however this advice is based on the fact that password hacking attacks have changed in the past years. Nearly all password hacking attacks are now automated, dictionary based attacks. They operate on the back of the criminal value chain that provides us with viruses, spam and credit card fraud. Therefore it is unlikely that your browsers password storage is target of the attack. Even if this turned out to be changing in the future, it will be comparatively easy to secure this through operating system or browser updates. For now what you can do in addition is to secure the browser database with a safe password.

High security

For your on-line banking, Ebay/Trademe, Email and any other website where your money can be spent you should use memorable and safe passwords. There are 2 good methods to create these:

- Create a sentence about something you are passionate about or a personal life experience and make the password an abbreviation of the sentence. Try to get numbers and punctuation marks in there - I try to relate them to the meaning of my sentence or use them in a visual way (* for sun, # for fence). There are some good tutorials on the web, but there are also a lot of bad ones.
Simply taking a single word and adding numbers and punctuation is not nearly as safe.

- Memorize a random password

This may sound difficult, but you should give it a try. Create a number of random password until you find one that contain syllables that you can pronounce, but that don't mean anything. Write it down and speak the password out loud in your mind. Use the password and try to memorize it.

For business owners commissioning websites and software systems

Our advice is to choose one of the two methods above, depending on the nature of your website or systems. If your website contains commercial information such as your competitors pricing you got from somewhere, your clients email addresses or even more commercially sensitive information, choose only secure passwords. You may need 15 minutes per employee and a mentor present to create a safe password, but it is a well worth investment of your time.

You should also assess independently, if your web development team (internal and external) abides by the recommendations below. Just like backups, this is not someone else's responsibility - it is yours.

For web and software developers

We advise the following guidelines of best practice for web and software developers

- Do not store passwords in clear text, choose one-way encryption (MD5, SHA1) and use password salting
- Do not roll your own log-in routine, use major open source frameworks, where thousands have reviewed security
- Do not use security by obscurity, it doesn't help a bit
- Do not create unsafe passwords for testing, always use random ones and store in browser, store in safe places (your SSL encrypted Wiki)
- Only chosen libraries and platforms that have regular security audits and patches applied swiftly.
- Apply security updates swiftly

Common comments and objections

1) "I won't use this website for anything much or I won't use it for long"

How do you know that? Here are a couple of examples:

- You created an unsafe password to comment on Gawker's Gizmodo site, but 2 months later you start a computer hardware business and want to use your comments to build your personal brand

- You build an internal web database at your work place just for fun (or as a prototype), but your company ends up using it in a production capacity for the next 10 years

- Your commenting password is stolen and used for political comments not of your own, but 5 years down the track your dream career is put to a halt, as your potential employer decides to attribute these comments to you.

2) "No one will be able to guess this word, its not even English"

Not safe - Hacking dictionaries contain all words, place names and publicised, but invented words. This is for all languages of the world including Klingon, Elvish or whatever the next Tolkien invents in a book.

3) "I just replace i with 1, o with 0, e with 3"

Not safe, hacking dictionaries do this as well

4) I just concatenate 2 words and put a number in-between

Not safe, hacking dictionaries do this as well

5) Its too hard to do this stuff, I don't have time for this

You certainly won't have much time, if you have to clean up the mess created by a password breach in your work place or personal life.

How passwords are stored

Clear text/Unencrypted

Some website still store passwords in clear text. Stay clear of these and let them know you don't approve. You can see if they store your password unencrypted if they send you your self chosen password when you request a password reset.

One way encrypted

A better way is to store your password with one way encryption, this is a mathematical routine that turns your password into gibberish, but there is no known way to reverse the process for this routine. In reality, there are always ways ways being discussed to gain at least partial information about your password from a one-way encryption routine, so the choice of routine is a moving (albeit slow moving) target.
The encrypted password - or "hash" - is the same for each password that is the same. When you enter your password for log in, the website repeats the encryption routine and compares the results to check if you entered the correct password.
This storage is safe, but not for weak passwords if the encrypted database of passwords is stolen.

Salted and one way encrypted

With password "salting" your password is combined with random text to make the resulting encrypted "hash" differs, even if you use the same password for 2 different accounts. This makes your password safe, even if the encrypted database of passwords is stolen

How dictionary attacks work

On website log ins

A dictionary attack will try to log in to user accounts simply by trying passwords from a dictionary of words. Obviously if you look at the beginning of the article, you'll see that such attacks will have great success by just trying the 20 top passwords, but even with other dictionary words, such attacks are easily feasible. 
This is because there are millions of infected computers available that can be used to actually do the work for you at no cost whatsoever for the criminal doing the attack.

On stolen password databases

If a hacker has obtained a stolen, one-way encrypted, but not salted password database, he can also create a set of hashes on all words, variants and combinations in his dictionary. These hashes can then be compared to the password database, immediately revealing all unsafe passwords in the database.

Summary

Password security is everyone's job - do your part.

Kind Regards,

Jochen Daum

Chief Automation Officer
Automatem Ltd


Christmas Holidays: 23 Dec, 5pm - 3 Jan, 8am

Phone: 09 630 3425
Mobile: 021 567 853
Email: jd@automatem.co.nz
Skype: jochendaum
Website: www.automatem.co.nz
http://twitter.com/automatem
http://nz.linkedin.com/in/automatem
http://www.aucklandbusinessnetworking.co.nz

Automatem is hiring: Joomla Component Developer - 2 months - Auckland

Automatem is looking for a Joomla component/module developer to work on a range of complex Joomla projects. You need to have proven commercial experience with building Joomla backend and frontend components, either with the Joomla 1.5 MVC or a similar template-driven Joomla component system. We require you to have a good understanding of Joomla's component, module and plugin system, as well as a reasonable understanding of AJAX and common Javascript libraries.
Slice and build from Photoshop is not required for this role, however it may be beneficial.

We expect you to be fluent with basic SVN version management and that you can adhere to a range of coding standards.

Knowledge of Virtuemart, Jevents, Payment Gateway integration would be of great benefit.

We expect applicants to have good time management skills and the ability to map out and plan development of a complex Joomla component with small amounts of supervision.

This role is based in our Mt Eden office in Auckland, based on 32 – 40h per week. It is expected to start on 10 Jan 2010. You need to be available to work an assessment day at our office before start of the role – we will pay you an allowance for this day.

The salary range for this role is around $25-$35 per hour.

Application procedure:

Send your CV to employment@automatem.co.nz and fill out the following application form: http://ow.ly/3hZCf We will not be able to consider your application without the application form.

Recruitment Companies: This role is limited to direct applicants until Mon 6 Dec 2010, 1pm.

Taking exams today to become 1 of 12 accredited chocolate ambassadors

2010-09-29_09

 

I found this shop that sells 100% coco and 100% New Zealand chocolate only.

However they will only sell me Christmas hampers only through 1 of 12 official chocolate ambassadors. So I decided to become certified.

Exams on today!

Kind Regards,
Jochen

jd@automatem.co.nz
www.automatem.co.nz
+64 9 630 3425
+64 21 567 853
skype: jochendaum
twitter.com/automatem

you need to own your website IP and have a backup, was: [NZHerald] Sites down in legal dispute

On the weekend I saw this story in the NZ Herald: "Sites down in legal dispute" I see this and similar sort of things happening around me all the time. These disputes can be in public - such as website or email down - or they can be hidden from view - such as when they are used as part of commercial negotiation.

My recommendation to business owners is:

CEO ownership

Stop burying your head in the sand and take ownership. Your website is your most important marketing asset, if you like it or not. Its the owners or CEO's responsibility to make sure frameworks are in place, so it is working at all times. The same goes for email.

The first question people will ask if your website is down is if you are in receivership yourself. You don't want your customers to think this.

Domain names

Take an audit of your domain name. For this you can go to http://whois.domaintools.com

 

  • Are you actually listed in the "Registrant details" or is it your web developer. If this is not someone at your company you are in serious trouble - the person listed can take your domain - and therefore your website and emails - away from you at any point in time.

  • Is the person listed actually still working for you? Is the email address correct? Actually do have somone send a test email.

  • Do you have a UDAI for the domain? This is a code that allows you to move a .nz domain name to a different hosting provider. It is better to have it on hand for emergency restore purposes.

  • Can you prove you are actually at the address listed? For some secure certificates and in a dispute this may be of value. Check for bank statements, invoices or similar that are send to this address at the entity listed in the domain name records. |
    Finally, does the correct entity own the domain? For liability purposes you may have separate companies for intellectual property and day to day business. Talk to your lawyer. To check on this.

  • When does the domain expire? Will the person listed as billing contact actually pay it? Will they pay it on time? If you are with Xtra - they renew domains constantly with short expiry periods, therefore make sure you renew your domain name it when you move from Xtra to someone else.

Website source code

Make sure you own your website code or that you have an unlimited right to use it in any way you see fit. That was your expectation right from the start, wasn't it? Well, you better check it. We expect at least 60% of websites produced in Auckland to be owned by the actual creator of the website, with no right for the owner to use it somewhere else or use it without the attached hosting contract.

On the other hand as developers we understand that you don't want your web developer to reinvent the wheel every time they build a website for someone. Therefore we recommend you choose Open Source licensing for your website code. We find that a lot of lawyers have little experience open source licensing, but it still is a widely and successfully used concept.

Current source code and database

To be actually able to restore your website somewhere else you need a current working copy of your website and your database. We recommend you have this sent automatically from your web developers server to you every week.

Restore tests

To be sure an emergency restore will work, you need to do a restore test regularly - say every 3-6 months. This means you restore the website on a different server, by a different developer or your in-house staff. Dointg this, you also gain some other insights that you either need or which are useful in case of an emergency:

  • Documentation of how to restore your website somewhere else – request this from the person doing the test restore run.

  • What Internet Service Provider (ISP) to use for your website in an emergency.
    While you're at it, you should also check where the restore-test-ISP actually has their servers located, it may be the same location where your current website is. Choose someone with a different location.
    Note: there is an ISP that gives you access to the Internet and one that stores your website - they do not have to be the same.

  • You gain someone who has experience restoring your website.

Questions?

Please contact me directly:

Jochen Daum

Chief Automation Officer

Phone: +64 9 630 3425
Mobile: +64 21 567 853
Email: jd@automatem.co.nz
Skype: jochendaum
Website: www.automatem.co.nz
http://twitter.com/automatem
http://nz.linkedin.com/in/automatem

Goodbye PHPDbEditTk, welcome #Symfony

Not many people know that I've been managing an open source programming framework on Sourceforge for the past 7 years. Tonight I'm consciously saying goodbye to it.

When I did my first PHP project in 2001 - a training CD for Wella AG (together with Bauer & Guse in Germany) I found myself having to build a back end interface to manage data in about 8 tables. I decided that I could just write the code for it in files like add_model.php, edit_model.php, delete_model.php, then copy and paste it into another set of files and simply search and replace what was necessary. But after 2 days of fixing copy/paste, search/replace mistakes I had the guts full and tried to build something that coudl do the work for me. I ended up building an array of fields for each table, assuming that every primary key was called 'id' and routing everything through an index.php file. It worked ok, including building SQL queries such as "select * from model where id=5" and "delete from model where id=5".

When I started work in New Zealand for Styrofirm in 2002 I refined the scripts I had to allow for custom edit buttons, search filters, paging, different field types and many more things. It worked very well as a tool for building administration interfaces for websites and we even build a small internal CRM system on it. 

Later that year I started work as an employee of Cabletalk and I had to figure out a way not doing everything from scratch again, but at the same time not have my employer owning all the code and having to do everything from scratch again afterwards. The solution was to put the code onto Sourceforge, licence it under LGPL and keep committing my changes to the CVS repository at Sourceforge. The name "PHPDBEditTk" was borne out of necessity. It is simply what the set of scripts did, compressed into the space that Sourceforge allows for project names (PHP Database Editing Toolkit)

Over the years I've made various improvements to the project, however I never got around to set up proper instructions and documentation on how to use the framework. It worked well enough for my own projects (and still does) and over time improvements got smaller and smaller. The reason for that was threefold: A lot of things I wanted the framework to do worked well and didn't require a lot of changes to the framework (or the changes didn't feel like they belonged into the framework). Secondly, some changes seemed too difficult/ to daunting/would have required a rewrite of the framework. Finally, over time I got too busy with my business and simply didn't have time to develop the framework.

So while the framework did its job, I started looking around for something better. It had to be a framework that is widely used and was strong at building admin interfaces ('Excel sheets on the web" as my customers say) for databases out of the box very quickly. I found quite early on that Symfony seemed to suit my requirements and style, but it was difficult using a new framework on a project on deadline. I was lucky to have Mikael on board to use Symfony on two client projects.

So no is the time to decide to jump into Symfony whole-heartedly and say good bye PHPDbEditTk!

P.S.: I will probably work with PHPDbEditTk projects every work day for the next 5 years.

 

Desk available for rent, Mt Eden, Auckland, $95 p.w.

After many years of sharing our office, one of my tenants has decided
to move out and move on.

Therefore we have 1 or 2 desks available for a party to move in,
available 23rd August 2010 (earlier if you are only 1 person) . This
is ideal if you are working from home or otherwise need a desk in an
office. The environment suits very well for: Graphic Designer, Web
Developer, Software Developer, Online Business or anyone else with low
to moderate phone traffic.

Location: 560 Mt Eden Rd, Mt Eden, Auckland, 1024

Facilities:

- 1 or 2 desks, set of drawers, space for own book shelves
- kitchen, veranda, garden view and client meeting room shared with
other office tenants of building
- power, Internet access and outbound phone calls included
- you can have your own phone line and Internet

1 desk: $95 per week ex GST
2 desks: $160 per week ex GST

No minimum term, no commitment

2 references required.


Kind Regards,

Jochen Daum

Chief Automation Officer
Automatem Ltd

Phone: 09 630 3425
Mobile: 021 567 853
Email: jd@automatem.co.nz
Skype: jochendaum
Website: www.automatem.co.nz
http://twitter.com/automatem
http://nz.linkedin.com/in/automatem
http://www.xing.com/go/invite/3425509.181107
http://www.aucklandbusinessnetworking.co.nz