lesscode.org

Tim Bray posted a doozy a few minutes ago on the changing face of PR, analysis, and trade press:

The Old Public Relations

The mechanism was easy to write down, it went like this:

1. Senior management, with a lot of input from marketing people, would work out a company’s message and talking points.

2. Internal marketing people, working with PR consultants, would try to burn the message into the retinas of the trade press and analysts.

3. The journalists and analysts would do what they do: the whorish segment of the profession regurgitating the company messages to the attention of very few, the independent thinkers producing sometimes-useful analysis of what the companies were really up to.

It never worked that well; to start with, it was expensive and slow. Also, there was a huge conflict of interest: the journalists and analysts, who positioned themselves as independents, were in fact mostly on the payroll of the companies trying to push the messages.

The New Public Relations

The new PR pipeline is a lot shorter, simpler, and wider:

1. Senior management works out a company’s goals and messages.

2. Management works hard to make sure that the employees understand them.

3. The people who are really doing the work tell the story to the world, directly.

It’s important to realize that this change in authority is partially responsible for the rise of LAMP/friends as a viable platform for building real applications. That is to say, these technologies have always been a capable platform but the change in how people receive and participate in information has allowed these technologies to step up and finally begin claiming the problem areas they fill so well.

Our biggest problem is that we don’t talk loud enough.

As an example, would 37signals have been possible even two years ago? I really don’t think so; at least, not in its current form. As much as I love the technical and methodological stuff those guys are pushing out, what I think is most interesting is how well they understand The New Public Relations.

What are you guys thinking about Fundable.org? Newsforge has the short and sweet:

The concept, while unique, is quite simple. Anyone who has a product or service to sell, or needs monetary support for a charitable cause, or who wants to organize a group purchase, posts their requirement on Fundable.org. They specify the number of contributors needed and the amount of money required from each. They also specify a deadline by which to raise the needed capital. Fundable.org holds all contributions until the total amount requested is received, or the deadline is reached. If, by the deadline, the amount contributed is less than the required amount, the project is scrapped and the contributors receive a full refund.

I’ve yet to see a working method of raising money on the web for collaborative development and I’m skeptical by default besides. That being said, this does have some interesting ideas attached to it that I’ve not seen elsewhere and sometimes a slight modification makes all the difference.

I’m sorry to say that I don’t think this is going to be a revolution in funding projects based on anonymous donation but here’s a few scenarios where Fundable may be useful in collaborative development:

User Groups

I’m a member of a few local area user groups and there’s a frequent need to raise money: food, venues, food, fix things that are broken at people’s houses, and food.

Of course, telling everyone to bring $5 to the next meeting works pretty well, too.

Infrastructure

Hardware and bandwidth can be had for cheap if you can find a nice little group of people with OS and configuration tastes similar to your own. I’d rather split up a root level, dedicated, co-located box between 5 others than deal with a shared or virtual box.

Here’s something to try: go out and find a nice hosting plan, determine the optimal number of people needed to get the cost down but not tax the box, throw something up on fundable and then point people to it via weblog. I’d think you may have a decent chance of working something out.

Oh well, it will be interesting to see the types of uses people put Fundable to in the next few months.

A big part of what we’re all trying to do is bring the complexity of our systems and working environments way down compared to that of the established industry. Complexity is a tricky concept, however, and I believe it is wise to understand when it is and isn’t okay to play the “too complex” card.

Bill de hÓra introduced me to the idea that the that’s not simple argument is often not very different from the that won’t scale argument we’ve all come to despise:

These days we are all complexity experts and simplicity mavens. Once upon a time a popular way to trash somebody’s technical design without having to bother to present a cogent argument was to point at it and say it would never scale. Today we just can call designs we don’t like complex - that’s even better because while it’s unlikely to happen, you can actually have a meaningful conversation about scale. Complexity on the other hand is comparatively vague - indeed there is only one simple definition of simplicity for software.

But David Meggison does an excellent job of describing why the simplicity argument is a healthy way of thinking about systems anyway:

… it’s really a fundamental change in the burden of proof (in the popular sense of the obligation to defend a position). With the rise of agile development and worse is better, we’ve shifted from “required until proven unnecessary” 10 years ago to “unnecessary until proven required” today, and I think that’s a change for the better — after all, if we’re uncertain either way, we might as well pick the option that requires less time and money. So when people say “the project is too complex,” what they’re really saying is “prove to me that these features are justified.”

He goes on to talk about the relationship between “unnecessary until proven required” and The Presumption of Innocence, which is widley considered to be an essential right of peoples belonging to a democratic society.

I propose that we adopt “unnecessary until proven required”, which is perhaps also known as YAGNI, as one of the “strength traits” that help ensure the successful evolution of a system.

I just had a chance to finally listen to the latest Gillmor Gang…

UPDATE: I goofed and ended up listening to the June 2004 episode. It’s still an excellent episode–and one I don’t remember hearing last year–but is not nearly as timely as I had thought.

… with Mitchell Kertzman, a venture capitalist with Hummer Winblad Venture Partners. He talks about an investment that’s in progress. I’m just going to dump out a whole segment from him because it’s great stuff:

We are actually in the process of making an investment in a company where open source is a key part of their plan in two ways. The first is, that they are building on top of the so called “open source commodity stack” — that’s everything from x86 processors, to Linux OS, to the whole LAMP aggregation of core software stack.

So I think one of the huge breakthroughs–I’ve been running software companies before I did this for 30 years–and in my experience in running software companies that deal in enterprise software you may have a product that you sell to an enterprise customer but you had to drag around this expensive platform with you.

So if I want to sell my software to a customer, I might be selling them my software for a few hundred thousand dollars but in order to run it they might have to buy some expensive Sun servers and some Oracle databases and some application servers and the cost of that stack meant that you were pulling a boat anchor around with you. The commodity stack, with its performance and quality these days, means that software companies don’t have to do that anymore.

You don’t have to spend .5 million dollars of your first round of financing to buy the infrastructure you need to build and test your products. And it also means that you can sell your software to customers without the incremental costs.

The company we’re looking at, and all companies we’re looking at now are taking advantage of the lower cost to market of the commodity stack.

I think that’s a huge development in software..

The Money understands why less code is important, that’s a Good Thing, even if you don’t think you need it.

Mitchell goes on to talk about why Java isn’t looking as attractive as it once did when the hype machine was in full swing and the world was a different place:

When I first started doing this, everyone was doing J2EE backends. … We still have companies that are doing J2EE backends but the questions that are being asked lately are very interesting. When Java was first being developed, the portability of Java was a huge part of its attractiveness. The write-once, deploy-anywhere was extremely compelling. The interesting thing, if you stop and look now is that Linux essentially has made that, ummmm, almost moot. There are now really two environments: there is .NET and there is Linux. And so the portability of Java, since, according to Microsoft, it doesn’t have a place in the .NET environment, therefore if you’re non-Microsoft you really have one environment that you’re deploying to (if you look into the future). So it does raise the question of why you need to carry this JVM around with you if you don’t need portability.

And then the other interesting question is that, Java was useful when, uhh, if you consider that multi-tier or distributed application architectures used to communicate essentially for years by communicating binary data. Today, applications are really communicating by passing text back and forth, you know, XML or HTML, and Java isn’t particularly good at text processing so there’s an interesting development in [looking] at the scripting languages–at the P part of LAMP - PHP, Python, Perl, which are very good at text handling. This company we’re investing in is taking advantage of that.

So I think we’re in an interesting period of evaluation on Java.

Ahh man, this whole damn episode is amazing. I’m not transcribing the whole thing, just go listen to it.

While we’re talking about books, O’Reilly’s top 25 is interesting. I’m reproducing it here so as to preserve it in time:

1. Mac OS X Tiger Pocket Guide
2. Linux Pocket Guide
3. Head First Design Patterns
4. Head First Java
5. Dreamweaver MX 2004: The Missing Manual
6. Photoshop Elements 3: The Missing Manual
7. Knoppix Hacks
8. iMovie HD & iDVD 5: The Missing Manual
9. Adobe Photoshop CS One-on-One
10. Mac OS X Tiger for Unix Geeks
11. SQL Pocket Guide
12. iPhoto 5: The Missing Manual
13. iPod and iTunes: The Missing Manual
14. Learning Perl
15. CSS Pocket Reference
16. Learning Unix for Mac OS X Tiger
17. Learning Python
18. JavaScript: The Definitive Guide
19. MAKE: Technology on Your Time Volume 02
20. Learning Java
21. The Art of Project Management
22. Cascading Style Sheets: The Definitive Guide
23. Windows XP Hacks
24. Classic Shell Scripting
25. Programming Perl

Okay, so, we can all agree that selling OS X manuals is a good idea. But take those away along with the design related books and what do you get:

1. Linux Pocket Guide
2. Head First Design Patterns
3. Head First Java
4. SQL Pocket Guide
5. Learning Perl
6. CSS Pocket Reference (I’m leaving this in because CSS is a developer’s friend too and most Java people still use table based design. :)
7. Learning Python
8. JavaScript: The Definitive Guide
9. Cascading Style Sheets: The Definitive Guide
10. Classic Shell Scripting
11. Programming Perl

While Java has two books on top, the rest of the list shows that there’s no lack of support for LAMPish technologies and the new set of Rails books are likely to break through onto this list as well. So why doesn’t the analyst coverage break down similarly? Why aren’t popular magazines and online publications dedicating half of their content to this stuff?

And just for fun, let’s add the design related titles back in. How many design people do you know that are working primarily in JSP or ASP when they don’t absolutely have to? My experience is that designers stay as far away from the mess that is the current state of mainstream software development as possible. It’s not because they don’t understand as many developers like to assume, it’s because it’s a complete mess.

Attention software industry tool vendors, publications, and analyst groups: you’re not paying attention to your developers. Please shift your attention to the tools we’ve built and join us in doing something useful.