RMS - Pants on his head, pencils up his nose

Does anyone remember the final episode of Blackadder Goes Forth? It is the one where Blackadder attempts to avoid being send to certain death by pretending to be mad. He puts his pants on his head and sticks pencils up his nose because .. well, people who do that are obviously insane.


I think that Richard Stallman is trying to pull a similar trick with this posting. I appreciate everything the man has done for the software community, but he seems to have transcended reality at this point. Maybe he's frightened that with the current economic downturn that wold war is inevitable and that he's going to be conscripted - he's smarter than us all, and he's putting his insanity defence in place right now.

My arms hurt so much, I wish they would fall off! || Architects beware

I went indoor-climbing last night for the first time in over a year. Right now my arms hurt so much that I'd rather not have them. It's not like they're doing me much good just now anyway - my hands are largely incapable of closing and the opposable thumb seems like a dim and distant dream.

I did learn a few lessons last night, about climbing and about the way my mind works. When I arrived at the centre and approached the first wall, I realised that I had no idea how the equipment worked. I couldn't remember how to tie myself on, and I couldn't remember how to set up the belay end of the rope. That information had completely fallen out of my head. I've done it a thousand time but ... I still couldn't quite recall how to do it.

The bit I found most surprising is that I was sure I knew how, I was sure I'd forgotten nothing at all; right up until the point when I tried to do it. There's a lesson there for all software architects (me included) - if you don't write software regularly you will forget things about the process. Not only that, but you won't know what you've forgotten. If you forget enough about the process you're no longer an asset to your company. You're just a guy who's telling people how to belay, and keep other people alive, who can't actually belay. Don't be that guy.

My second lesson is about trust. I climb with my wife and my best friend. These are people I trust implicitly. I'd also given my equipment a thorough check over before I went out, so I was sure it was working fine. Even with that, I was terrified on my first few assents. Now, I don't like heights, I hate them in fact. In the dictionary, under acrophobia it has a picture of me .. screaming whilst standing on a shoe-box. But I'd got over it whilst climbing, a year ago I could climb freely without fear. Now I was sweating and panting and wearing out my arms clinging onto the wall for dear, sweet life. Why?

To me, it seems that there are things that come naturally to us, and things that don't. For me, being off the ground is not natural. By working at it, I got to a point where I was no longer afraid, then I began to enjoy it. At the same time it was good exercise that was helping me get a little bit fitter each time I went. When I stopped going, my confidence and trust in what I had learned started to erode and my natural fears and distrust started to come to the surface again. When we don't practice something, we not only loose our understanding of it, we can start to believe things that are actively not true. Yes, brother architect, I'm talking to you again. Ever wondered why so many companies are lumbered with crappy products that the group architect purchased? Because they were out of touch, and began to believe the easy lies of silver-bullet vendors. They believed in the things that appealed to their core nature rather than the hard-won truths they'd struggled so hard to find.

When we don't keep our skills sharp, we forget things. When we don't practice our craft, we believe things that aren't true.

Questions about power consumption

In this week's episode of 'Rob Shows His Ignorance', I've a couple of questions regarding power consumption and computers.

1. If I'm watching a video at native resolution - so if the picture is 640x480 I have it consuming that many pixels on my screen, will that consume less power than if it has to transform it to a different size/resolution? I imagine that there's extra processing required to map it onto a bigger image, but I don't know if modern hardware is sensitive enough to this level of work for it to be a noticeable difference. Will the GPU be able to work at a lower level? Is my basic premise reasonable? Since most video is compressed in some way, is there in fact an extra step required to transpose the picture onto a higher resolution or is that all taken care of within the decompression process? I ask, because I always have the impression that my laptop battery doesn't last as long when I watch video in full screen mode as it does if I watch it in a window.

2. If I turn the volume up on my laptop, as I understand it, more power is being used to create bigger vibrations in the speaker. Now, I was watching a video (Bill Buxton's Mix09 Keynote) and I noticed that there was a volume control on it. If I turn the volume up from within the flash application, I'd be surprised if it changed the amount of power running to my speaker so ... it gets louder for the same amount of energy. Since even my twenty year old physics tells me that you can't make energy for free .. this doesn't seem right. What's going on? Am I just deluded that my laptop controls volume by a variable resistor just like my great-grandfather's crystal set?

It is at times like these, that I wish I had a background in EE so that I didn't have to expose my vulnerable, underbelly of ignorance

Bill Buxton at Mix09

After watching Dan Roam's presentation, I decided to see what else looked good from Mix09. The day 1 keynote from Bill Buxton - available right now on the front page of the site gave me an insight into the mind of a designer that I didn't have before.

Bill talks extensively about the history of industrial design and its rise during the great depression and that we can take the opportunities of the current financial crisis and use them to make usability design a priority.

I'm not sure if his logic, that crisis periods are inherently periods where design can prosper, is well founded but .. let's hope it is. When you're stuck in a financial hole, digging may not help but just sitting there doing nothing certainly won't work. If innovative design and engineering can give us hope - let's get to it.

Some of the ideas that Bill pushed strongly on were the notions that design has to be fast, has to be iterative and that only trying one approach to solving a problem leads to sub-optimal solutions. I've tried the first two of those ideas in development and they work like a charm. I wonder what it would be like to try to get several different solutions to the same problem in parallel? Perhaps that's really what's going on in the Java web framework world, or the .NET DI container world. Perhaps, rather than being frustrated by the problem of trying to learn and decide amongst multiple choices we should rejoice that we have options; we should be pleased that we get to choose the design that we believe in most.

The other big take-away that I got from Bill's presentation was that in selling something you shouldn't try to sell the item itself. You should sell the experience of using/owning the item. I can see this as a useful tool when trying to build software and also to make engineering decisions. Build software that will lead to a positive user experience and you'll be a success. When considering two engineering alternatives, ask people to imagine the experience of living with that decision. Ask the technologist to put on his negative/remember-all-the-times-things-didn't-work-the-way-they-should hat on and ask him to imagine what life would be like.

I've said it before, and I'l say it again. I love watching smart, passionate individuals talking passionately about their passions.

Dan Roam - Doodling Your Way To Success

Mixing it up in Vegas: In this engrossing and entertaining presentation Dan Roam talks about his theories on sketches and how they unlock creativity and help communication and consensus gathering amongst groups.

I really enjoyed it, I'll certainly try some of these ideas out, and I will probably buy the book. All those positives aside, three things do bother me about his presentation.

1. He starts off by saying that you don't have to be able to draw at all to use his methods. That his ideas revolve around using simple shapes to communicate. Then he uses slide after slide filled with drawings that, whilst simple, are of a much higher standard than I could ever produce. (Yes I am that artistically challenged.) If simple diagrams are what you need to communicate .. why doesn't he use any?

2. I'm willing to accept that using drawings as a means of communication engages parts of our brains that would otherwise lie dormant. What are the trade-offs? What are we sacrificing? Trading in my ability to logically critique something for my ability to create new ideas is something I'd want to do sometimes. When is it good, when is it not? Give me the down as well as the up.

3. I became suspicious when the Dan claimed that we can use pictures to solve any problem. That's obviously nonsense. At best we might be able to describe any problem using pictures. Describing and solving are two different things. Don't believe me? OK, well, all of my grandparents are dead. I love them, even those I never met. I'd like them back. Please provide me with the drawing that solves that problem.

Before I go any farther, I'd like to be clear that I'm a Black Pen Guy, When I talk, I like to stand in front of a white-board and scribble. I love to throw a marker to people and say, "show me what you mean". Giving me a tool to make me better at design, communication and problem analysis is wonderful. That's all you need to do to sell it to me.

Anyway, rants aside, this is a really interesting presentation with oodles of interesting ideas and anecdotes.

(Via Clarke Ching.)


Pair programming == Brussels sprouts

I like the teams I run to use pair programming, because the end product is better. I've also heard lots of people say that they don't want to do it.

I have a theory that pair programming is the brussels sprout of the technology world. Lots of people don't eat them because, not because they think they're bad for you, but just because they don't like them

I have no children. When I do, they'll eat brussels sprouts. I won't do it because I want them to be sad, or to make those little sicky faces that children pull when they put something unfamiliar in their mouth. I'll do it because I want them to be healthy, productive and to live a long time.

My War Paint & Why I Wear It

When I go to work I like to wear a suit. I also like to wear a tie. I like to wear thick, starched, stiff collared shirts with thick double cuffs. I like hard soled, thick leather shoes. I like to be aware of how I'm dressed, without being uncomfortable.

Why? It's my war paint. In the same way that a Native American or a Massai tribesman or an ancient Celtic warrior put on face paint as a symbol that they were no longer at rest, they were now at war, and wholly committed to the task at hand. That's how I want to feel when I go to work. I'm there, I want to get a job done. I'm committed. I'm not in the same frame of mind as when I'm at home with my wife watching TV.

Is it really necessary? Yes, for me it is. I like to make friends with the people I work with, the people I work for and the people that work for me. But friendship holds a trap. I'm not at work just to hang out and shoot-the-breeze. I'm there to create, to achieve and to add value. My war paint keeps me focussed.

Zed Shaw is not normal

I've just watched Zed Shaw's THERE WILL BE PORN: 10 Dangerous Ideas Nobody Should Implement which thankfully contains neither porn, nor ten ideas. He sings, he plays music, he insults people he likes, he has some number of ideas that people should never implement which is less than ten that he talks about and he swears a great deal.

You know the old chestnut whereby both art and porn are hard to describe but "I'll know it when I see it". Well, this is neither. But for some reason I enjoyed watching it.

There's a lot of history you have to have lived through to really understand it; you'll know if you know. If you do, give his farewell speech a listen. If you don't ... he plays a mean guitar.

Renaissance Technologist

I've been working on my CV recently and finding it hard to quantify what I do and am. I've worked in almost every capacity in technology:

  • Developer

  • Process Engineer

  • Architect

  • Team Leader

  • Project Manager

  • Analyst

  • Product Manager

  • Programme Manager

  • Service Delivery Manager

  • Support Engineer

  • Agile Coach

  • RUP Mentor

  • Technology Evangelist and Trainer

  • Trouble-shooter

And a whole bunch of other roles that don't even have good names. I've loved every one of these roles, I'm fascinated with every aspect of technology. Beyond that, I like to flatter myself that I've acquitted myself well in all of these roles. I love technology, I love managing people. I love guiding and participation of the creation of something out of nothing. Well, nothing more than sweat, tears, inspiration and a compiler.

I've always loved the idea of being a polymath, a renaissance man - but sadly my interests have always been restricted to one field. Luckily it is a pretty big field and there are few people that have become masters of it all. I'm not there. Not even close. But I'd like to be.

Everyone needs a goal in life. "Be the best you can be at the thing you love" works for me.

Rob's Document/Door Test

Here's a rule of thumb I like to use.

Q. How do you know when a document is too long to be useful?

A. Print it out and try to slip it under the door of the person you wrote it for. If it doesn't fit ... it's too big.

As a an addendum to my test; whilst you're at the door, open it, go inside, and say hello. Nine times out of ten, that'll do more good than the document.


Software - No crisis, but we can do better.

In a post entitled, simply, Software, Rafael de F. Ferreira juxtaposes quotes from James Bach, Erik Meijer and an Alan Kay/Phil Windley amalgam to put together an intriguing argument that quality software doesn't exist, people no longer care that quality software doesn't exist, computing is in its infancy and we don't know much yet, but we're also not really learning so things aren't getting better.

I'm not sure I buy it. In fact I'm sure it is bunk. I've said for a long time that The Software Crisis doesn't exist. As an industry we create more, better software cheaper than ever before. WTF is the crisis?

Can we do better? Yes.

So why do people talk about a crisis? Because programming attracts smart, dedicated, attention-to-detail-oriented, meticulous, perfectionists who're never going to be happy. People who're always going to want to do better. For many people - including me - software is my art, my hobby, my career, my passion. I want it to be great. I won't accept second best. I won't accept shoddy or badly done or half-hearted. I want to build the best .. whatever the hell it is I'm working on.

Equally, I won't accept people telling me what a bad job the software industry does any more. We don't do a bad job, we do the best job of writing software that anyone ever has in the history of the world. Possibly the universe.

Can we do better? Yes. Can you beat me with the crisis stick? No, sir, you may not.

My good friend, Clarke Ching, today proposed that we reach out to universities and colleges to help them teach students the things we'd like them to know when they graduate. I've done some of this in the past working with universities and colleges in the US and the UK, it was very rewarding. I'd love to do more.

IBM to buy Sun?

This trickle down from Reuters looks and sounds legit.

I'm not sure how I feel about this. Mostly positive I think. Sun has been chasing the client-side dream for the last couple of years ( well forever really, but with renewed vigour of late ) with twaddle such as JavaFX. Personally, I've written mostly server side Java. That's what I expect to continue to do. If I was going to write client side code, I wouldn't use JavaFX. I can't think of a single reason why I would choose JavaFX over Flash or Swing or GWT or SWT or ... anything.

Sun, who've been financially constrained for a long time, have been focussing resources on client side development and that has led to stagnation and lack of drive on the core Java language. Take the complete failure to deliver on closures for example - Sun had other priorities, so nothing happened. IBM sells hardware, lots of back end hardware. They make money out of said hardware and want people to write as many apps as possible for them. I have hope that they can deliver on the sort of roadmap that will make me happy.

I had a conversation with the head of Sun's R&D department about three years ago. We talked about their hardware platform and the fact that they were producing hardware with massive numbers of processors and cores, and that each of the cores were comparatively slow. This sort of architecture seems ideal for hosting PHP/RoR/CGI/share-nothing apps and kind of poor for hosting Java apps. I asked him if he felt that was true, and what they were planning to do about it. He said, yes their hardware and software sweet-spots had diverged and that they had some ideas about how to realign their offerings. As far as I can tell, things are still the same today.

Don't get me wrong. I like Sun. They've given me lots of free stuff, for a long time, and in return I've given them ... nothing. That's not quite true, I've had Solaris boxes ripped out and replaced with IBM Blades running Linux. So, I've given them less than nothing. Sheesh, no wonder their stock price has gone down the drain.

Lean/Agile, Language Progress and the .NET Community

I'm writing this post because a lot of my friends are dyed-in-the-wool Java and Ruby developers who believe that nothing good ever came out of Redmond. I'd like them to think again.

Over the last few weeks I've been listening to podcasts that have come out of the .NET community: Elegant Code's Code Cast, Scott Hanselman's Hanselminutes and Herding Code and overall my reaction has been, "Wow, the Microsoft/.NET community is really starting to get to grips with Lean and Agile". This wasn't the case the last time I worked intensively with .NET about three years ago, back then it seemed that MS and .NET developers were living in the dark ages.

Listening to people working from within Microsoft talking about using Scrum and XP and Lean and how it is making their development better is heart-warming to someone who's been pushing this message for the last ten years.

That Microsoft are dogfooding their own applications, and changing them to make them work better in support of Agile methods is fantastic news. Microsoft can do a lot of good if they support these ideas openly, and that seems to be their intention.

Microsoft isn't just making strides in the process department though, the advances they've made in the CLR and the languages that run on it are really starting to pay dividends. As this post from Matthew Podwysocki shows, the generative effects of advancing the language and the platform.

That the .NET platform has been pulling ahead of Java in the feature department for a while now hasn't been a secret. But now, for the first time, I'm starting to see people using these features and talking about these features to solve significant problems rather than brandishing them as 'the new hotness'.

If only it wasn't tied to Windows, I'd buy some.


Passion Isn't Enough

Bob Martin has a presentation he gave at a JAOO conference up on InfoQ. The title of the presentation is Craftsmanship and Ethics, which is somewhat misleading since the presentation is basically on Software Craftsmanship prefixed with "we should be craftsmen, craftsmen should have ethics, it'd be unethical not to". I was a little disappointed by that - I was interested in his thoughts on ethics and how they relate to the development.

Overall it is an entertaining presentation that will leave the Agile and SC groups nodding and leave those with a different mind-set shaking their heads as normal. I enjoy watching passionate people talking passionately about their passions... so this was fun; but I don't think it changed any minds or taught anybody anything they didn't know.

I'm assuming that the crowd at a JAOO event is composed of experienced professionals who care about and investigate their industry. To effect change it isn't enough to speak passionately. It isn't enough to tell experienced professionals what you think or feel - they have their own thoughts and feelings and there's no reason they should supplant their own with yours. People need compelling reasons to change, they need people to provide compelling solutions to immediate problems, they need to believe that by changing they are shedding risk rather than increasing their risk profile. Passion isn't enough.

Uncle Bob, and the other leading figures in our profession have the opportunity to speak directly to thousands, indeed millions of developers each year, and I don't think that what they're doing is working. The Tony Robbins style pitch is enough to get people fired up at the conference, it doesn't carry enough momentum to provide a solid take-home.

I'm reminded of Geoffrey Moore's Crossing The Chasm: Agile, Lean, Craftsmanship, all these ideas have been sold to the innovators and perhaps even the early adopters, we need to cross the chasm to get to the next group of technologists - the early majority. Even this isn't enough, though. We haven't got the message through to project mangers, business analysts or customers, let alone C*O types. We can present compelling cases when we talk to people one-to-one, but the ideas haven't taken root in these communities; in Chasm terms we still don't have a hook in the innovators there.

If we advanced the management and technology communities in parallel we'd have a much better chance of improving the way software development is done.

How do we do it? Well, first off, I think we need to stop talking about quality, top talking about Agile and Lean and Craftsmanship and start talking about value. Value is what everyone wants. Developers want to create value, managers want value created, customers want to buy valuable software.

I firmly believe quality leads to value, but telling people they should want quality leads nowhere. Tell someone they want value and they retort, "Of course I do, how do I get it?". NOW you can say, "Well, every industry in the world has come to accept that building in quality leads to higher value." At this point, I've never heard anyone say, "Hmm, that sounds hokey. Go build me some shit. I'm sure that my best path to value is by heading through latrine-town."

When technologists, managers and customers talk about value, they may not all understand it in the same terms. At least not at first. But until they agree on what value is, there's no way to build successful products or relationships.

The idea that people might not have the same understanding of value is something that many technologists don't get right off the bat. To explain it, I need to take back something I said a few lines ago. I don't believe that quality always leads to value. This also brings me back to Uncle Bob's talk.

I have worked in environments where financial opportunities would arise out of nowhere, last for a few days or a couple of weeks and disappear. In these cases, the opportunity to make millions of dollars a day can exist if you can(in abstract terms) get information in, process it and send it back out within a specified time period. Oh, and the countdown on how long you can do this for has already started. Every moment between now and shipping costs a non-trivial sum of money. In these cases, value comes from shipping. The software might have problems - if it crashes every fifteen minutes night and day, that's OK .. we'll run ten copies on ten machines and have ten interns sit and watch them clicking the icon every time it falls over. The software doesn't have passwords or security, that's OK we can hire a rent-a-cop with a gun to keep people away from the computers.

Overall, doing this makes money. Sure, over the first few days the team try to improve the quality so that half the interns can go home - but the software is going in the bin in a week .. improvements beyond basic stability are a drain on assets nothing more.

I've heard developers shout about this being a terrible, shoddy way to do software and insult the developers who build it. I may even have been one of them. That's because I wasn't thinking about generating value with my software, I was only thinking about software for the sake of software.

Now I think about value, I can understand why people build software like that. I can also understand that we can get that software out of the door faster by looking at what we build in each case and trying to pull together some pieces that they can glue together the next time an opportunity arises. Pieces that'll let us be EVEN faster to market next time. That's value.

My point, value isn't a universal truth. Value is relative to the situation. If everyone talks about value at the start, and forms a common understanding we can fit everything else into the framework this gives us.

Uncle Bob, luminaries of the development world, talk about value. Please.

How To Castrate A Bull

This morning I opened up a copy of Dave Hitz 'How To Castrate A Bull' and I've been totally blown away. I read it cover-to-cover without standing up. This was unfortunate because I was in the bath. I filled the tub over and over with hot water until I was done because I couldn't bear to stop to dry myself until I had got to the end.

Dave (someone else I'm on first name terms with by dint of having read his writings) tells of his experiences as a founder of NetApp. The book is filled with amusing stories and side-bars, coupled with sage and hard-won advice, recounting of failures and successes with equal honesty, passing on of lessons learned from others and a thousand tiny observations each a gem in of itself.

I only wish Dave had a second, parallel company at the same time so he'd have a sequel.

Damien Katz ... wow

Damien Katz, and his family, sold their house and lived off their savings so that he could write free software.

His honesty and his story left me, literally, in tears. But truly inspired.

Please watch it.

Macports - Bringing the Unix UI Experience to the Mac

Trying to get CouchDB set up, I've had to install macports. Macports is a neat tool that makes a lot of apps and libraries available for the Mac. Many of these are old-school Unix libraries and it seems that it isn't just the code that the Macport team wanted to bring to the Mac - they wanted to bring the Unix user experience too.

I downloaded the installer and ran it. It gave me a lovely progress bar that pottered from zero to about seventy percent in 2 mins or so. Then it just sat there. After about twenty five minutes I tried to stop it .. and it said "No, I'm not going to stop". Before killing it I decided to see if it was doing anything. I opened a terminal and ran top. It seemed that there were multiple rsync processes consuming CPU. Digging around I found that the installer was actually doing something - downloading files from the mother-ship. I decided not to kill it and another 20 minutes later it finished.

Why do people do this sort of thing? If they'd written an installed that flashed up a message saying "This could take a while" I'd be content to wait. Giving me a progress bar that just stops for most of an hour is madness, the worst possible UI decision. Showing me nothing would have been better because then, at least, it wouldn't have looked broken.

I'm now all stressed because I have code on my system written by people who thought that UI was a good idea. What other insanity do they have in store?

Erlang in Practice Screencasts

I've now watched all eight episodes of Erlang in Practice a series of screencasts by Kevin Smith[1] and it was money well spent.

Having watched a expert write in Erlang for six hours, I feel I have a much better understanding of the flow of Erlang development. It isn't as good as sitting down with someone and pair-programming, but it is as close as I can get. Watching someone write code is a very different experience from reading a book on the subject: each has something unique to offer. A book can teach you syntax and tricks and libraries and all of the static parts of a language, it can't show you the way an expert thinks. The way an expert gets from A to B, the mistakes they make, the paths they go down before refactoring; things that even experts can't tell you, but they can show you.

The only thing I didn't like about the 'casts were that on a number of occasions Kevin ( I feel like we're best buds after spending the day together ) would make a mistake that I spotted and, no matter how much I yelled at the screen, I couldn't get him to fix it. It felt like I was at the theatre shouting "look behind you" and the actors stubbornly refused to comply. That's a minor thing, though. Informative, entertaining and (if you're geek enough) fun.

I hope he does more.

[1] Sadly not that Kevin Smith, seeing Erlang written by Silent Bob would be great.

Is the Erlang community too experimental?

My foray into the World of Erlang continues. I'm excited and energised by the new and interesting things I'm discovering. Learning to think in terms of messages passed between processes isn't easy, or natural yet; but I'm getting there.

I do have some concerns though. Erlang has been around for a very long time ( in computer years ) and has a few people who date back to the beginning still involved. Many members of the Erlang community are, however, quite new to the language and are working at trying lots of different ideas - some of them new, some of them translations of ideas from other languages.

What this means, for me, is that when I look around for a library to perform a certain task I'll find a bunch of different options, each with a different approach, none of them are stable and none of them have any strong hints about their future. It seems that Erlang is such a fertile place for experimentation, and the community is so young, that projects spring up, are used briefly and are abandoned before they reach their potential.

Take web-frameworks for example. I want a UI for an app I'm considering and a web-ui would be just-the-thing. I looked around and there are loads of different web frameworks and web servers. I don't have any trust that any of them will be actively maintained three years from now. I can't create a critical dependency between my work and a project that may or may not have a future.

I'm not criticising people for their efforts (I will in a moment though) people are entitled to spend their time and efforts in whatever way they want. Erlang has drawn innovators, early adopters and those dissatisfied with the tools and options they had elsewhere. The relatively blank canvas is, I'm sure, what attracted many people to the language. There's new ground to be broken, clean slates to be drawn on and blank sheets to be filled with ideas. All wonderful stuff.

The problem I have isn't with innovation and creativity. The problem I have is with people who innovate, create, persuade other people to use what they are creating and then get bored and forget it. If you write up some code, dump it on git-hub and say "world, it is there if you want it" that's one thing. If you create a project, put together a pretty project page telling people why it is cool and why they should use it then you've created a social contract you're obliged to support your work. If you don't want to make the commitment then don't act like you are.

People who create, advertise and evangelise, then abandon open source projects are doing the world an active dis-service. Why?

  • There's only so much time and attention to go round. Many/most projects are not original - they're similar to other existing projects. By creating an only slightly divergent copy of something you dilute the market of the original, reducing their chances of success.

  • Open Source has, in most fields, killed off the market for commercial products. I don't have the choice to pay someone for a quality product because the market has been devalued. Killing off the commercial market and replacing it with nothing is a distressing scenario.

  • It provides an impediment to those who might follow through on an idea. Many in the Open Source community dislike the idea of forking or creating copy-cat projects. If you create an abandon-ware project you've added an extra barrier for others to cross.

Just to be clear here. I don't have a problem with Open Source. I've used it for many years. I've spent some of the last few years providing technical support for Open Source applications and libraries. I've found good Open Source projects to be, without question, the equal of their commercial counterparts. I've watched innovation and change come from the Open Source community, positively affecting the entire industry. I like Open Source. I get annoyed by Open Source dilettantes and their here today/gone tomorrow behaviour.

I have an Open Source project of my own. I'm not going to point to it, because I don't want you to use it. I made the code available for myself and a couple of other people. I have a disclaimer on it saying "there's no good reason for you to use this" because it is treading old ground and I'm not going to maintain it. If someone finds it and uses it .. that's fine, if nobody ever does that's fine too. But nobody will ever believe that it is a project they can depend on.

So what's my point?

The Erlang community right now has many smart people in it. They have lots of ideas and they want to try them out. There's almost as many ideas as people, so there are mostly small communities and unstable projects. There's certainly exceptions to this rule such as CouchDB and RabbitMQ, but in general I don't see many significant communities building significant projects. For my benefit, and that of everyone else, I'd like that to change.

If you're about to create a project or release some code you have as an Open Source project, please consider these question:

  • If you have an idea that you'd like to try out, could you do it under the banner of an existing project?

  • If you want to build a product, just like X. Could you contact the people who build X and help them out? You'd probably end up with something better than either of you could on your own.

  • If you just want a creative outlet, do you have to start from a blank slate or would working with a community on something in existence be fulfilling?

  • Would picking up someone else's abandon-ware and carrying that forward be viable?

  • Are you really going to devote the time necessary to maintain this for the next n years? Where n is a number that at least twice as big as you'd expect.

  • Do you just want to show people something cool that you bashed together? If so, have you made it clear that this was just a one-off that you've made available to that people can learn from it or carry on if they're interested?

Whatever else people may tell you, Java has been a success because of the communities associated with it. In particular the Apache Jakarta community was instrumental in making Java the phenomenon that it became. They had rules, they had standards, they had ethics and lots of smart people talking and building great things. Companies and individuals would adopt projects because they were Apache products - it was a name you could trust. The name and the community had respect and trust. Smart individuals looking to work on interesting problems gravitated there. Those with interesting ideas would go there and find other like-minded people to help them.

Erlang doesn't seem to have that community, not yet anyway. But it does have enough people to create that community. At the moment they're consumed by experimentation, and there is no central place or group that seems to be a likely candidate. Some languages never coalesce around a community and are forever fragmented and experimental e.g. Smalltalk. This isn't necessarily bad, things are what they are.

Right now, I'm enthusiastic and energised, but I'm also cautious and concerned. Erlang looks like it could be ideal for the problem I want to solve; I just don't think I trust the basket enough to put all my eggs in it.

Looks like I'm just in time...

Looks like I jumped aboard the Erlang train just in time. If I'd waited any longer I might have missed the chance to be Munctional.