A developer evangelist fills an important role for a company. They serve as a communicator, a liason, a thoughful voice and more importantly, an integral part of the web development community. Few people encompass all of that as well as Christian Heilmann. Currently working as a principal technical evangelist at Mozilla, he's literally written the book on developer envangelism and offers up some insightful nuggest on his work.

I am a tad worried at the moment how fashionable it has become to have a "developer evangelist" for your company and how many people call themselves this without coming from a developer background or actually releasing any technical information. It seems people have realised the potential and the benefits of having someone like this in their company - which does make me really happy.

On the other hand it is up to us to keep our territory clean and point out repeatedly that developer evangelism is not product marketing.

If someone only talks about their products without even acknowledging the competition or offering developers a choice, it is not developer evangelism, but plain and simple marketing or advertising.

A big change I am seeing is that our traditional channels for publication have been terribly washed out. Both LinkedIn and Slideshare is not as usable to me, as it used to be as they are full of noise. Hence, I am moving to Google+ and Facebook for a lot of my outreach. We have a lot of tools cropping up, too. Lots to test out and play with. I am really excited about what Lanyrd has up its sleeve for us - watch this space.

Half an hour on the cross-trainer is either wasted or useful for keeping up. Your choice.

RSS feeds - that's why the news about Google Reader really hit me hard. Feedly is a good replacement, though, and I installed Fever on my server. A lot of it is also constantly looking at what your peers are doing. So don't go to conferences, give your talk and leave - watch what others are doing and check YouTube and others to keep up to date with what your competition is talking about. I watch tech talks in the gym - half an hour on the cross-trainer is either wasted or useful for keeping up. Your choice. The constant change in the web development world is just that - a constant. If you want to be a web developer, you need to keep up to date all the time. That is what makes our job so amazing. There is no certificate to pay for; you need to learn all the time.

Get yourself out there as much as possible. Take part in discussion threads, go to meetups, speak at unconferences, attend hackathons, and see what people are doing in their outreach that annoys you - then do it better. For Mozillians (which includes volunteers), we have the Developer Evangelism Reps - a group I am leading that get all the materials we create, training and in-person coaching. I needed to start this as I can't clone myself.

Mozilla doesn't mind at all if we report about anything that makes the web better.

I don't have to wait for any product to be ready to talk about it, and there are no secrets. Where it was tricky in Yahoo to praise Google products, Mozilla doesn't mind at all if we report about anything that makes the web better. That freedom is the main difference. As someone working for Mozilla, I get invited by other companies to work with them and there is no issue with this. I also get information before it comes out, as Mozilla is a channel, not a commercial competitor. For example, the training videos we did together would have been a nightmare to get OKed by Yahoo; with Mozilla they were no issue at all. Mozilla gives me an incredible amount of freedom, and a great community to tap into. I also can answer all questions with "the code is available, check it there".

As I don't know all the facts, I'd refrain from guessing what the reason was, and I am not tainted enough to think that my opinion would matter to a large corporation. Running a show like Yahoo isn't easy, there are a lot of demands on you - many of which we don't know about.

Personally, I found that remote employees can be incredibly effective if you trust them and they love what they do. When some people abuse that freedom, it can get tricky. I am happy to work from wherever (airports, cafes and hotels mostly) and I think this is the future of working. We have the technology, we shouldn't have to work like we did fifty years ago. If we keep up a fixed 9-5 separation between work and "real life" we make work a thing to make money and life a thing to enjoy ourselves. That doesn't have to be the case.

There seems to be a massive difference between US and European conferences.

That is a very tough question to answer. I found that the quality of talks gets better and better each year, and I love some of the new talents that cropped up in the last years. People like Brad Frost, Jake Archibald and Lea Verou are a joy to see.

What I discovered, though, is that events as an institution have quite a short half-life. A lot of events that have been around for a long time descend into mediocrity or "here are 12 tracks to choose from" behemoths. Size doesn't make a conference great. On the contrary, I find that smaller events have much higher quality. I also don't believe in roadshows, repeating the same talks around the world whilst the same information is also available in recordings already. But they are hugely successful, so what do I know about organising them?

There seems to be a massive difference between US and European conferences. US conferences are much more of a "well, another one" thing and both the speakers and the audience are much more lack-lustre. As a speaker in Europe, be ready to deliver something new and useful or get very direct and short feedback from the audience. People here want to get their money's worth and attend each talk and each activity around the event. In the US, I see a lot of coming and going and exchanging of business cards, rather than caring about what speakers have to say. Of course not everywhere, but the institution of IT events is much older in the US than anywhere else. With this, comes a bit of tedium and people getting bored. Unconferences tried to disrupt that but outgrew their initial anarchic approach. And don't get me started on our overload of "hackathons" right now. A lot are just very thinly veiled user tests and/or hiring exercises.

Stories. Implementation examples and how what you show makes a difference to them. Anyone can look up technical details. So don't explain the how in a twenty minute live coding session that people can't remember five minutes later. Instead, point people where to find out more after the event. Of course, people are amazed when you show technical magic and flex your coder muscles showing ten impossible things in five lines of code, but that is not helping anyone. If anything, it perpetuates the notion of "developers/designers" and "rockstar ninja overlords" which in my book needs to die.

Checking the web for new talent in our comments, meeting them at events, and then encouraging them to submit papers and get themselves out there. Coaching them and helping them with finding the story in their materials. A lot of people are scared of speaking, as the same people are invited everywhere. So maybe saying no and proposing a local newcomer in your stead to conference organisers is a good thing. Also, mentioning people's work in your talks helps a lot.

I've spoken quite in detail about this lately, and I am sensing that the pendulum is starting to swing in the other direction. I don't think that one will replace the other at all, but that native apps and web apps have different goals.

Web apps are the evolution of web sites. We move things we do on Desktop with installed apps to the web - Google Docs being a great example of that, or most of us using web mail clients instead of Desktop ones.

Native apps, by their very nature, are meant to be fixed in their state and do one thing well. That means that they always give a superior experience for this use case, but it also means that they are limited and get boring or pointless quicker than a web solution.

Both can exist happily side by side.

Web solutions are more flexible; I can give you a mobile and a desktop experience, both with catered interfaces that make most sense to that environment and synced with each other. Native apps don't do that. I need to repeat the same challenges on Temple Run on my tablet and my mobile, rather than syncing the two.

The reason is not that this isn't technically possible. The reason is that native apps are products and their job is to sell and sell more and make money with upgrades. They are built with built-in obsolescence in mind, much like games on CDs and Floppies were. Apps are there to make people want the next iteration of hardware, so they can use the shinier version.

Web apps are there to be used and upgraded without you realizing it. Both can exist happily side by side. In order to make the web more interesting for current native developers, we need better tooling and conversion tools. ASM.js is a great start for that - it allows developers to write in C++ in the environment they are comfortable in, and convert to JavaScript with a tool. Adobe, also, is building some great tools for developers to stick with Flash, but render out Canvas/WebGL solutions.

The web is the best distribution platform if you want to spread far. If you need to control your distribution, it is scary for some. We can have both. I am not scared by native apps - if anything, I see them as a fad, and cross-platform distribution means you need to duplicate work. That is not clever.

Frankly, we messed up as web developers.

Frankly, we messed up as web developers. When the iPhone came out and claimed HTML5 as its platform, everybody built solutions that only worked on this device. This is incredibly shortsighted and a repetition of the mistakes that we made in the 90s, which gave us multi-million dollar enterprise finance systems that only run in IE6 and cost a lot to maintain and upgrade. Far too many web solutions released in the last year are "iPhone only", and, thus, fail to deliver a good web experience and look and perform badly, when compared to native apps. They are the worst of both worlds. Luckily, the fallacy of "if it works in Webkit, it works everywhere" should become obvious even to the most confused developers. Web technologies are not there to serve one browser or one piece of hardware. Doing this means you strip them of their main powers.

It means developers have to realise that WebKit isn't WebKit, and Android isn't iOS, and OSX isn't iOS. I think in the long run, it means that both Chrome and Safari will get better, and means that Apple needs to ramp up their web game by hiring more engineers, or be honest about it and go fully native.

It succeeds already against both of them, as it isn't meant to compete with them.

It succeeds already against both of them, as it isn't meant to compete with them. FirefoxOS is there to bring web-enabled mobile devices to markets that now only have feature phones.

The main gripe that Mozilla had with the move of web consumption to mobile devices is that it means only a few people on this planet get access to this new way of web distribution. Devices running iOS are not available world-wide and are very expensive. Android devices can be affordable and are sold in more countries, but the affordable hardware doesn't get an upgraded browser capable of new HTML5 and CSS technologies. If you want Chrome as the main browser, you need to have the newest phones. Both Firefox for Android and Opera are available back toward phones that run Froyo, but we had no phones that came out of the box with those browsers installed. That is why Mozilla created Firefox OS - to fill the gap of emerging markets being not supported by mobile technologies.

Firefox OS phones will be very affordable, can easily be customised to different market's needs, and end users do not need to have a credit card to buy content and apps. Apps can be installed from a marketplace, but also from anywhere on the web. Using a web-search functionality, users can find apps for their needs, not by name or review. And anyone can release compatible apps for the phone without having to rely on a marketplace to distribute their apps. It is bringing the web to the phone, not the other way around. These are also the reasons why Firefox OS has eighteen mobile service partners and four hardware partners, whereas other open platforms trying to compete in the high-end market are struggling to find distributors.

Firefox OS apps are plain HTML5 apps with a manifest file.

Firefox OS apps are plain HTML5 apps with a manifest file and more APIs to play with. Nothing stops developers from building apps that work well on all mobile browsers, while adding the extra functionality of WebAPIs to the apps on Firefox OS. None of the APIs are closed or hidden - they are all proposed to the standards bodies and many have already been implemented in other browsers (for example, the Battery API). The dynamic app search in Firefox OS encourages building mobile web sites for all browsers, which will be shown as the preview of your app. What that means is that people, for example, can search for "Skyfall" (the movie) and get IMDB.com as the first app offered to them. When they click on the icon, IMDB's mobile web site loads into a frame into the search interface and people can start using it. If they like it, a long-tap installs the IMDB app which is nothing more than the mobile site with a manifest (in the simplest form). Firefox OS apps add to what we currently build as mobile sites; it doesn't replace them.

Helped, very much. Of course, it annoyed a part of our user groups - especially the enterprise users - but most developers welcome a browser that continuously improves, especially when that happens silently (which it now does on Windows). Leaving the process of updating a browser up to the user on the web is simply dangerous. Nearly all security holes are based on out-dated software or plugins.

The web tooling space started with the Firebug extension - at least to the large market. Frontpage Express had some debugging tools that preceded it, but Firebug was the big, simple to use tool we needed. Every other browser then just copied that model in their in-built developer tools. Mozilla still keeps Firebug up to date and innovates for it, but in the long run, we are building native tools in the browser. Personally, I ditched Firebug a while ago for the in-built tools. These do not copy Firebug 1:1, because we wanted to avoid the overload of options that Firebug has become. Chrome's Devtools release weekly, providing incredibly useful things for certain edge cases, and add more and more to the in-browser tooling. The developer tools of Firefox now take a more modular approach. Instead of giving you the kitchen sink, you can enable and disable just what you need. This can look more complex upfront, but helps developers to specialize. We built quite a few different bits in there, too, like a 3D display of the depth of the DOM, a scratchpad to write larger JavaScript blocks and execute them against the page, and a command line to control the whole development tools with keyboard commands, thus, enabling developers to debug without a mouse.

As with anything, keeping up-to-date on what the browser offers you is of the most importance. That, and finding what really makes you more effective, rather than what looks useful at first glance, but then lies forgotten a few minutes later.