raganwald
Tuesday, November 21, 2006
  The world of selling products for developers who choose their own tools
Eric Sink on Borland spinning their development tools off into a separate company:
Welcome [back] to the world of selling products for developers who choose their own tools. This is SourceGear’s path as well. Lots of companies prefer to sell products for developers whose tools are chosen for them. Your parent company is one example. That strategy can be quite lucrative, but it’s not very satisfying.

It’s tough to sell products to developers. You get squeezed from both ends: lots of developers are cheapskates. Some are so religiously opposed to paying for tools that they stay up nights making free copies of commercial tools instead of inventing new ways to help developers.

And from the other end, companies that can fly upper management to Atlantic City have huge marketing budgets and work very hard convincing companies that they should dictate every last detail of the development process from the top down.

So building a business on the basis of developers (and development teams) who simultaneously have the freedom to choose their own tools and also are open to the idea of paying for high-quality tools that make their working lives better requires a huge amount of patience and passion.

I recall using TurboPascal many years ago to write a multi-user business application many, many years ago. I wish the descendants of that development team every success. And, if I ever find myself building a team within the MSFT ecosystem, I would certainly give SourceGear or TeamPrise a call.

If you’re going to commit to a career in harmony with your values, it’s nice to do business with people who have made the same commitment.
 

Comments on “The world of selling products for developers who choose their own tools:




<< Home
Reg Braithwaite


Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

Books
What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

Share
rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

Beauty
IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

Work
The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Management
Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

Notation
The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Opinion
Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

Whimsey
The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

History
06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /