The Changelog: Software Development, Open Source - Appcelerator's Titanium and Titanium Mobile (Interview)

Episode Date: January 14, 2010

Marshall Culpepper joined the show to talk about Appcelerator's Titanium Desktop and Titanium Mobile.

Welcome to the ChangeLog 008, 1st of 2010. I am Adam Stachowiak. And I am Wayne Netherland. We've got a great show for you today. We talked to Marshall Culpepper from AppCelerator and Titanium. Fun little project. It's kind of wild to see that kind of project be open source. As big as it can be and what it is. Yeah, I know. It's cool that you can fork it and contribute and add some features right back to it. I went to a JavaScript meetup with Marshall by happenstance last night. He was there and he gave the spiel about

AppCelerator and Titanium and I think the biggest surprise from the group was, wow, that's open source? Exactly. Did he have any swag with him? He did not. He did not. This was the first or second meetup of a JavaScript group here in

Dallas, so I don't know that he was prepared for the swag and handing out the items we talked about in the interview, but it's a pretty good turnout. In terms of swag, I really am looking forward to them pushing hard on that wristband thing. Not to kind of follow in Gary V's

footstep, but I really like the phrase, code hard. That's awesome. Code strong? Code strong. Code strong. Sorry. Code strong. See, I took it and I went all pump up the volume with it. I went back to Christian Slater and said, hey, code strong, code hard, same thing.

You went way back in the vault for that one. Way, way back. Hey, you like the movie analogy, so I thought I'd pull one out myself. There you go. There you go. I got to do my part. First show of 2010. Are you excited? The upcoming new year?

Man, this is going to be a freaking awesome year. I can't tell you how excited I am about the stuff we're working on together and what this podcast is doing. We get lots of people on Twitter talking to us and we get our various shares of emails about the show and what it's doing. So I'm really looking forward to being able to put the spotlight on a lot of good open source projects

and certainly helping put some more community efforts into talking about software and software development and practices and community and all that stuff. I'm super jazzed. There's a lot of stuff going on in the open source space, and I'm dying to talk about some of the Skunkworks things that you and I have been developing over the last month or so. We've been quiet on the blog just because we've got some cool new features at the site coming out that we're not quite ready to talk about.

But our main aim there is to shine a spotlight on some folks doing some great things with open source. And I think you'll be excited once everyone sees that. Yeah, absolutely. So in this podcast with Marshall, we talked about mobile. I mean, and we asked this question in the podcast, but is this year going to be, you know, finally going to be the year of mobile? And, you know, before we got on this intro here, I posted a link to you, and it was an article at Fast Company entitled Ford Upgrades Its Hands-Free Connectivity System and, and prepares to add apps. And I'm just wondering if Ford is taking the whole iPhone approach by putting this very sophisticated platform into each of its cars and what that's going to do for developers to open up one more market for us to develop against.

You're talking about the Sync platform for Microsoft that's in Ford's, right? Well, they're taking it a step further by going with MyFord Touch. It's going to be available in select 2011 and 2012 models. And I think really where they brought this home at was they brought that nifty feature I just mentioned, MyFord Touch, and that's going to actually be able to communicate to mobile devices too. So you might be able to have an iPhone or an Android phone or one of these newer smartphones, as we call them, do some very cool stuff like maybe voice updating your Twitter status, and that might finally become a reality.

It'll be interesting to see how open the platform is. A lot of times these car manufacturers tend to be very proprietary with their APIs and open them up to select partners. Hopefully it will be somewhat open and folks can get in there and create some new cool new features around those. But, you know, I guess that's good in a way that it's not wide open because it is a car after all and

you know, some rogue code. It's not like crashing your phone when you crash your car, right? Right, that's true. Well, hopefully the computer systems are kind of separated in some way. One would hope. I mean true. Well, hopefully the computer systems are kind of separated in some way. One would hope. One would hope. I mean the focus isn't Ford here, but I think – No pun intended.

Yeah, I mean – yeah, no pun intended. I mean Ford is an American company. I think it's nice to have some patrioticness in ourselves and look back to a company that was down in the stock market. Their stock was down to like $1.30. It's approaching $8 now or somewhere in that range. I mean, you've got to commend them for their comeback

and just hopefully they learn from their previous lessons and actually innovate this time. Sure, sure. Well, and another note, we heard back from Sea of Clouds here in the interview, and one of the news items this week was the Fix Me repo, and he's let us know that a winner has been chosen, and he's going to give us the juicy details here pretty soon. And once we get the results, we'll post a link and be sure and discuss it on the next show.

I thought it was kind of wild, that contest, as you'll hear in the podcast, but that's cool. It is cool. Open source bounty. Got a problem? Got some money to throw against it? Just put it out there and see who can solve it for you. So he lost $100 or he spent $100? How would you say that?

He invested $100 in crowdsourcing. Everything these days is crowdsourced, man. That's true. Mobile, I mean, it's just insane. Logo design, brand development, you name it. We've got to crowdsource the talent for the show and see what we can do with it. We should. We have.

We've asked on the podcast, we've asked people to suggest anybody, but we're still the hunters. Be sure and reiterate, if you've got fresh and new open source projects out there that you think everybody should take a look at, be sure and let us know. Submit at thechangelog.com or it's thechangelog.com slash submit and let us know. We'll tweet about your stuff. We're happy to help in any way we can. It's all about putting the spotlight on cool, fresh, new, open-source projects, and that's what we do. Absolutely.

Want to get to the interview? Yeah. All right, we're talking today with Marshall Culpepper from the AppCelerator project. Marshall, why don't you give us an idea of who you are and what you do at AppCelerator? Right now I'm working for AppCelerator, basically leading up the desktop team for our Titanium desktop product. And what that is is a project that allows you to write native applications for the desktop platform, whether that be Windows or Linux or OS X, using JavaScript and web technologies such as HTML, CSS. And we also have pluggable support for

Python, Ruby, and PHP right now. And so I mostly work on all aspects of all those different things I just listed off with another guy, Martin Robinson, who's really also an extremely technical guy. And we work pretty much around the clock trying to get it out. So right now our team is kind of small, but we're pretty dedicated and pretty hardworking. So we're hoping to get a 1.0 out pretty soon and looking forward to that. And then as far as my background goes, I've worked on various open source projects. Before Accelerator, I worked at Red Hat in the division of JBoss, working on JBoss IDE, which was a set of tools for writing and developing JBoss applications. So I've been using open source, been in the open source

world for a little over a decade now and just love being here and actually real thankful that I get to put food on the table writing open source software. Awesome. Yeah, we love open source too, man. You said you have a small team. What size is your team?

So the desktop team is only two people, me and another guy. That's really small. We're tiny. The mobile team is also two people and we have a few other developers that work on various other aspects of our platform like the backend because we have a cloud

piece and our developer tool and we also have developers who work specifically on some of the support issues and stuff like that. So our development team isn't necessarily tiny, but it is pretty small. We are a startup, so it's not a big company. And we're, you know, working really hard to get it out there so that we can, you know, start bringing in the dough and, you know, expanding the team. So let's talk about that for a second.

So you're hosting open source applications, and that's kind of the entry point into AppCelerator. But let's talk a little bit about your business model and what you plan for the AppCelerator, I guess, marketplace, the exchange. So, yeah, that was one of our original ideas. And I'm not sure if we're going down that route right away, but the way that we're kind of trying to monetize right now is basically we have a few different partner programs, and we're talking with, you know, people who want to distribute titanium desktop apps, you know, for licensing and things like that. So we have a few different approaches that we're trying to take

for getting people to pay us for premium content based on top of the open source software, mostly cloud-based and things like that, and then relicensing. But as far as the projects themselves, I guess titanium desktop and titanium mobile are both fully open source. There's no proprietary extensions that you guys have on top of those? Everything, yeah, everything, all the software is all free and open source? There's no proprietary extensions that you guys have on top of those? Everything, yeah, everything, all the software is all free and open source.

We don't have, like you said, there's no proprietary extensions unless they're created by the community, but I'm not aware of any. Everything we have right now is under the Apache 2 license. So it's all free and, you know, we don't, we have no plans and no,

you know, we're not going to bait and switch, anything like that. It's a pretty fundamental root level thing of ours that we want to make sure that that always stays that way. And if you're listening in at home or in the car, you can get to, hopefully not in the car, you can get to all of this code at github.com slash AppCelerator. And let's talk briefly, I guess, about Titanium Desktop. This is your area of focus at AppCelerator. How did the project come about, and what problems are you trying to solve with Titanium Desktop?

Yeah, so that's a good question. You know, we saw air early on, and we liked the idea of being able to write a native application using web technologies. We figured there's so many web developers in the world, and even amongst developers who don't consider using web technologies, we figured there's so many web developers in the world, and even amongst developers who don't consider themselves web developers, most of them are able to use web technologies fairly proficiently. So we saw that solution, and we thought, well, that's a really good idea, except the Adobe way of solving that was a little closed down. It wasn't as open as we had hoped it could be,

and it was very restrictive in terms of permissions. It didn't have all the rights that a normal desktop application did. And so there were a lot of technical things about it that we just weren't really happy with. So, you know, one day we sat down in Mountain View, which is where we're based, and we just said, you know, hey, why don't we try to do this on our own, a real true open source, you know, desktop SDK for, you know,

writing native apps using web technologies. And so that's what I did, you know, for probably about three or four weeks there. Coded pretty hard, and we got our first prototype out for OS X internally. And then once we saw that, we tackled Windows and we released 0.1 within just a few weeks of that. So that was our original goal, was to kind of tackle this. It's kind of this merge between

the traditional cross-platform desktop APIs where they've had trouble reaching a lot of inroads in terms of getting mass adoption, mainly because of the complexity of some of the languages used for those APIs like C++ or whatever. You know, tackling that problem as well as tackling the other problem, which was allowing web developers to send their content at a native level. People are kind of embracing this native app world where you have a native experience, native speed, deeper, richer integration into the operating system, things like that. So that was kind of our goal.

So I love the idea of leveraging the web development community because there's just tons of those guys out there and they're just growing every day with the internet becoming more and more prevalent in everybody's homes. It's spreading like wildfire. But where did this idea come from to truly

leverage that piece and what does it take to allow web technologies to code against various platforms? Well, it is not an easy task. As you might have looked at our code and figured out the low level details of some of the stuff can be very difficult from time to time. But that's part of what makes it fun from an engineering standpoint too.

But, yeah, so, you know, there's... In terms of, like, how we implemented it or, you know, some of those details, like in Windows OS X and Linux, we use WebKit. We just fork our own version of WebKit, and we have some hooks in there that we, you know, that we allow for some custom functionality that we have. And then in iPhone and Android, we have two different completely separate versions of

the code base because obviously Android is Java-based, iPhone is Objective-C-based. And so we have a lower level kind of integration there with Objective-C and Java. And then we more or less, in the beginning, what we did was we kind of took the web view and sort of, you know, over the URL layer or whatever, we had a native callback functionality so that you could call into Objective-C. So we would shim out, like, native APIs into JavaScript

so the developers didn't have to worry about, you know, the Objective-C way of doing things. And so we kind of made a common API across Android and iPhone doing that. And, of course, there are some specific APIs for each platform, which is actually one major thing that we like to highlight about our platform, but we can talk about that later. But we more or less allow you to use the native functionality of the phone itself, whether that be the APIs like geolocation or like

the accelerometer, you know, the camera, things like that. We also allow you to use the widgets of the platform. So like native buttons, native sliders, native tabs, native views, you know, those kinds of things that provide a richer experience to the end user, which just aren't possible in like a Safari based web app or, you know, something like that. So they provide, you know, faster response. They provide, you know, a more unified look to the app because it looks just like other native apps on the platform. So those are things that we really tried to focus on. I think right now probably Titanium Mobile is getting more buzz. Is that right? For sure. Yeah. I mean, mobile is blowing up for sure.

I think I was watching an Ignite and I was watching one of the videos, I think from Ignite One in Boulder. And one of the guys, it was like the very first Ignite presentation, and he was talking about mobile and how it's changed. And this was back in 2008. He was talking about mobile, and he was saying that 2009 would be the year of mobile. Has that happened yet? I mean, did I miss it, or has the year of mobile actually started yet? I think it has.

I mean, if you just take a look at the numbers that Apple is posting in terms of how many apps they've sold on the App Store and how many units they've been pushing. And I just, I think the general consensus in the market right now is that the perception that the consumer had before 2009 versus what it is today of what a phone is, what it should be, and what it, you know, is completely different. You know, I think that's, I think that's just very verified through, you know, the whole app store concept and, you know, people wanting to, you know, apps existed before the app store for Windows Mobile and other mobile platforms, but they weren't, they just weren't homogenous. You know what I mean? They weren't, you know, the experience wasn't, it wasn't easy, it wasn't seamless. And, you know, Apple has faults and, you know, the iPhone has faults

and, you know, we all know about AT&T, but, you know, what they've brought to the table in terms of, in my opinion, what they've brought to the table in terms of just making the whole experience seamless and kind of educating the consumer about what's possible has really changed the game in mobile. And I think it was. You know, it seems for a number of years we've gone – oscillated back and forth between client server type apps and web apps, apps that are delivered to the client, apps that are delivered in a browser.

It's kind of like the boot cut versus tapered leg fashion cycle, you know? Absolutely. But what's exciting about projects like this is you kind of get the idea that you can create hybrid applications that have a native look and feel where they need it, but can talk out to the cloud and get data from that angle as well. Just anecdotally, what do you find people building with these particular projects? Are they all pure native plays?

Are they kind of a combination of both? Well, I think you kind of hit the nail on the head there. I mean, one of the advantages of using native stuff with web technology is obviously you get kind of the best of both worlds. And we're kind of hoping to push that. And I mean, the emerging HTML5 standard and things that Google and, you know, other companies are doing right now, just kind of

all pushing on that merge of, you know, richer, deeper functionality into the main system, whether that be the iPhone or an Android phone or the desktop, you know, that deep, richer functionality integrated with the web, like AJAX and JSON and all these other great technologies that have allowed us to do really cool things on the web. The merging of those two things is a really good thing, and that's really what we're banking on. Let's talk a bit about the.8 release. I guess that's the latest release of Titanium Mobile. I see that Facebook Connect is now in there. What has that meant as far as, I guess, boosting a lot of the use cases for building mobile applications?

Well, I mean, this obviously is a great API for just about any kind of social media integration you can think of. And so this opens the door to all kinds of different possibilities. And I don't have any use cases off the top of my head that are using our new Facebook API, but I know that just thinking about it, you could think of several ways that you could use Facebook integration in a native API. You have much fuller, richer access to that whole set of metadata. Any other social networks in addition to Facebook? We don't have

I mean obviously like most of the social networks have like public AJAX JSON APIs so if we don't have it now it's pretty easy to integrate from that standpoint but we don't have integration for like native integration for Twitter or anything like that standpoint. But we don't have native integration for Twitter or anything like that yet.

I was going to ask something funny because I just caught an article earlier this morning when I was checking out TechCrunch and we were talking about Facebook. Is anybody aware that Facebook just got its own vitamin water flavor? Are you serious?

Yeah, seriously. You know the vitamin water company called, I serious? Yeah, seriously. You know the vitamin water company called, I think it's a French company, so it's Glaceau, I'm not sure how it's pronounced, but it's G-L-A-C-E-A-U. They just released a flavor called Connect. Nice.

And it's sponsored by and powered by Facebook. Is it blue? It's pink. It's pink. I don't know why it's not blue. Since we were talking about Facebook, I thought I'd just throw that little funny tidbit in there. That may be a sign of the impending apocalypse and social media bubble. About the oil collapse.

Yeah, I don't know. But it's funny, though, that Facebook is making such a huge push. I mean, every application you go to these days is allowing you to get into it or get started quickly through Facebook and adding your friends. And I think the more they push that boundary, too, I mean, it's helping, obviously,, you know, more and more pushed to because people will leverage that and begin to use it more because it has, you know, a certain

feature. You know, one of my favorite items of titanium desktop to switch back to the desktop for a moment was the wizard based new project application that allows you to bring your own JavaScript framework. Can you talk a bit about what decisions went into that particular feature and how it's made a difference? Oh, sure. Well, you know, actually, since Titanium is WebKit-based, which is the same engine that runs on Safari and Chrome and a number of other browsers, the iPhone, Mobile Safari,

we support all the major JavaScript libraries. They work out of the box. But like you said, one of the things we did in our project creation was allow you to automatically integrate with any of the libraries that you're used to. So we have most of the major AJAX libraries there, like jQuery and MooTools and Dojo and those kinds of libraries. They're all there, and you can just create your project,

select the library, and we just download the JavaScript. Or we have it bundled in. We can download it either way. And we can just throw it in your project structure. We include it in your HTML for you, and then you can just get started right away. And then we also have another feature that's similar to that called the Sandbox, which is interesting.

It allows you to just kind of prototype code in kind of like a text area kind of thing and just allows you to run it as a native app and just gives you an idea of what you can do with just small snippets of code and kind of quickly prototype functionality and then throw it in your project and then go from there. You mentioned before that WebKit has allowed you to code

against not just Windows and Mac, but also Linux. What is that, I guess, trying to code against one common API, but hitting multiple platforms? What has WebKit meant for what you're doing with Titanium? Well, I mean, WebKit is the center of our entire play, whether that be on mobile or desktop. We use WebKit in all of our platforms. And it's crucial to our product. Martin and I specifically, we've had a number of patches committed into WebKit, so we're contributors to WebKit as well. I was going to say, you guys might even be graduating into core contributors or core team.

Yeah, we're getting there. We don't have committer flags or anything like that yet, but we're graduating slowly through the ranks. I would say Martin has probably the most patches committed right now. I think he's probably got seven or eight patches committed, and I've got about four or five. Some of them are minor, some of them are major, but

at the end of the day, WebKit is crucial to our project. Back to what you said about the common API, it's actually not quite true. For each platform, there's actually a completely different API. What I meant was for the developer to use Titanium, they're coding against one single know, one single API, but, you know, behind the scenes, Titanium's taking care of interacting with different

APIs. Oh, right, yeah. Yeah, and that's, you know, that is always, that's always going to be a challenge for any, you know, cross-platform API of any kind, whether that's, you know, Titanium or whether that's Qt or, you know, any cross-platform API is going to have that problem.

But yeah, it's definitely been interesting and it's been a challenge. And the other aspect of that has been that for each platform, not only is there different APIs, but there's also different rendering engines, which those can cause inconsistencies in what people expect from... That's what I was wondering too. How do you handle that? How do you handle those inconsistencies in what people expect from, you know. Yeah, that's what I was wondering too. How do you handle that? Like how do you handle those inconsistencies? You know, I've got to imagine that as a developer, if I'm doing something and it doesn't react the way I think it should,

how do you handle that rebuttal back to the developer saying, you know, hey, I did something and it didn't work out like I thought it should? Well, you know, it depends on the issue. Like some of them are font-based, and with fonts, you know, obviously font metrics are going to be slightly different from platform to platform, specifically because some fonts aren't even available on one platform or another. So if you're using, for example, you know, Helvetica New, which I don't think exists by default on Windows,

that's not going to show up correctly. It's going to show up as, you know, Arial or some other font. So you have those kinds of issues which are fixable at the client side by the developer. And then you have other issues where, you know, there's pixel changes or, you know, you have, like we had a recent issue where fonts were being kind of cut off in specific cases in Windows. And that's why we have to go back to WebKit and say, hey, guys, this is broken. And then sometimes we'll find the fix and we'll submit the patch. Sometimes someone else is more knowledgeable on the WebKit team.

We'll find the problem and fix it there. But it's a downstream or an upstream whatever process. They find the bug here. We go to WebKit, you know, we talk it out with their developers. Sometimes we're the ones coding it, sometimes we're not. But at the end of the day, it helps, you know, it helps both projects, which is nice. When you're targeting multiple platforms like this, especially on the desktop, you know, one of the cool things about native apps is they take advantage of features that just aren't there on the other platforms. Do you find yourself coding to a least common denominator or a core set of functionality and then have extras based on platform from there? How do you handle those sorts of decisions?

That's a good question. So in mobile, it's been much more pronounced that we have kind of branches of functionality that work on iPhone and Android, like specific views that are only available on one platform, that kind of thing. But on the desktop, the story is a little different. The way we approached it originally was we wanted to provide, kind of like we said, a common set of APIs that work on all the platforms.

And we do have a few APIs that are platform-specific, but they're kind of few and far between right now. And we're hoping that after our 1.0 release, we're going to start shelling out more of the platform-specific stuff. So, yeah, that's something we want to do. But, you know, with a two-person team, we've got our plate full as it is right now. Do you have any way to track what features folks use when building out their applications? I'd be curious to know what sort of languages are winning out inside of Titanium, like Ruby or Python or PHP, to build out these applications. Well, the vast majority are going to be using JavaScript. But I don't really have raw numbers, but mostly what I have is anecdotal

just from the support forums where we try and help people through their problems. What I've seen mostly, I would say, other than JavaScript, would be Python. Python seems to be really heavily used. And PHP also is starting to take a pretty big undertaking. And we do have Ruby users too, a fair amount of them. But I wouldn't say quite as big as either one of those, unfortunately,

because I like Ruby too. But as soon as we released PHP support, which was in our last release, that was a huge bandwagon. We've pulled way more than we thought we would for PHP. Do you mind if we rewind for just a sec? It was a little bit earlier when we were talking about WebKit and you were talking about contributing to WebKit. And, Wynn, this is more like a conversation for me and you right now,

but, you know, Marshall, you're here too, so I'm hoping that you give some good feedback to this. But you'd mentioned, and since I don't contribute too much to other people's projects, I do some lightweight open source stuff, but I'm not a huge, huge contributor to big things like WebKit or Titanium, but you'd mention

commits and patches and stuff like that, and how many patches. In the open source developer community, is that a way to rank? In a way to say, well, I've got more patches than you? No, I wouldn't say so. You know, it really depends on the project, too. Because, you know, before this, like I said, I worked at JBoss.

And there I was a contributor to Eclipse because my project there was an Eclipse-based IDE, right? And so, you know, there are inevitably bugs in Eclipse that need to be fixed, and we would, you know, push those out. And depending on the project, you know, each project has its own kind of governance, you know, its own rules of how it's going to accept patches or it's going to accept commits. And depending on that, like, you know,

how many patches or how many people have to say this guy should be a committer before we accept him. So it really just boils down to at the end of the day, you know, how much have you contributed, I guess. And just, you know, a patch is a good way to quantify that. So when I say four or five patches or whatever, it's just a good way to say, you know, we've, we have been contributing back to WebKit and we, you know, we will continue to do so. And we hopefully, through those number of patches, as they see our value, we will be voted in as committers, and then we can start providing some more value there. Right. Well, behind the scenes, Wyn and I are doing some fun stuff, and I guess I shouldn't talk too much about that or release too much information about it,

but I just thought the notion of using the term a patch and being able to count how many patches you've contributed would be a way to more or less show the level of support for a project or your contribution to a project and give you a certain amount of rights based on a certain amount of patches.

Yeah, I think what Adam's poking at is one of the things that we've asked in doing the changelog is, what projects are out there, especially in GitHub since it's open, and who are creating those projects so that you know who to follow and what to watch

on GitHub. And we've just been anecdotally asking people, if you had to devise an algorithm, what would you put in an algorithm to figure out who was interesting and what was interesting to watch in GitHub? Oh, yeah. I definitely think forks would be a good way to go, because what we've seen, you know, we're on GitHub,

and, you know, our contributors across the board are forking our repository. And so anytime I see a fork of our repository, I can expect a patch sometime soon, most of the time. You mentioned briefly that every project has its own kind of governance and hierarchy of how it runs its project.

And I think that is one of the cool things that Git has introduced. And since it's decentralized, no longer do you find these fiefdoms of subversion repositories now that it's easy just to go fork a project. And really, whoever's got the most momentum and the most inertia really is running the project these days. Absolutely. Yeah, I guess if you slack off a bit,

you can easily lose control of your own project. If you take a five-month hiatus, the community might be like, yeah, the original is no longer the latest. Oh, and that happened just this morning. I got an email from GitHub where somebody had sent me a message asking about a particular bug in a repo that I've got, the tiny little JavaScript plug-in from almost a year and a half ago. And before I had a chance to respond,

there was someone else that had forked the repo that had visibility to the issue. They said, I've fixed it in my fork, and here you go. So that's just the power of open source. Right, and I guess if you So that's just the power of open source. Right. And I guess if you finally merge that back into yours, then you still retain, but otherwise you might be up to lose. That's right.

That's right. So keep up, right? Keep up. Exactly. Smooth, smooth, fast. Hey, Marshall, I wanted to switch gears for a minute and talk kind of marketing, what goes into getting a word out about an open source project, or in your case,

several open source projects. Can you talk for just a brief moment how you use Twitter and social media and meetups and things of that sort to get the word out about Titanium? Yeah, you know, we obviously, since we're a startup with, you know, fairly little money, we try to, you know, save money wherever we can, and marketing is one way we definitely have approached marketing from kind of a guerrilla point in terms of going through Twitter and Facebook well not Facebook quite as much but mostly Twitter and like you said meetups

I think it's really important because the bottom up approach I think has been proven to work the best for open source JBoss did the same when they were their own company. You know, we went through the developers, and the developers would bring the project up, and, you know, eventually their managers would say,

oh, this is a cool thing. You know, all of my developers are talking about it. Let's bring it in. Let's pay them a contract fee or whatever, you know, support fee. And, you know, that's how the business is run. And it's a great way to start an open source business. This is just kind of the next generation of that, utilizing Twitter, going to these local meetups.

When you know me, I like to be pretty much anywhere in Dallas that is talking about technology and start pumping titanium. That's just because I have a lot of energy for the project. But in general, our concept has been like we have, you know, Twitter. We have a lot of people who like the technology, and we'll just utilize that as much as we can. And another way we've, you know, gotten a lot of free marketing from our Twitter stream is from just kind of giving out swag, which is another thing. People love swag. So we have T-shirts and, you know, we have stickers and all that kind of stuff, bracelets.

And we'll just say, hey, help us promote the 08 release, which is what we did. We just had a big thing for if you help us promote the 08 release, we'll give you a free shirt and a free bracelet. And people ate it up. They wanted the swag. So there you go. I wonder if it would be cool to also get involved with some of these incubators or even the startup weekends that take place. I guess it's probably a little premature that first weekend for a startup weekend,

but I'm thinking Capital Factory or Y Combinator or some of the other incubator-style things, if it makes sense to go in and sponsor those or even get involved in those to foster that early development on one API and many platforms. Oh, yeah. That's a great idea. I unfortunately missed Dallas Startup Weekend, which was not too long ago. But, yeah, I definitely agree with you. I mean, there's a really great, I wouldn't say it's an incubator.

It's more of kind of a co-working setup called Go Habitat in downtown Dallas. And I frequent there probably once or twice a month just to plug myself in and kind of spread the word and see what people are doing. And inevitably, it works out well for the platform. I get people that are interested in coming to our IRC, you know, IRC channel or going to our support forums and start using our stuff. You also have the AppCelerator University too, right? And you guys were doing this, did that? What exactly was that?

Yeah, so AppCelerator University was another really great kind of guerrilla marketing campaign in my opinion. It was basically the idea was that we would send you all the stuff you need for free, which was the training material, the swag, and all that. And all you have to do is find a location and set up a time and, you know, tell people about it in your local area. And you have, more or less, you have our community teaching others who aren't in our community yet about our product. And it's great because, you know, we give them the free training. Like, the training that they would give, we give them the same training. And, you know, we help them through the material, and we help them with all that stuff. And at the end of the day, they have, A, the knowledge,

which helps them develop their own application better, and, B, they have the fire to go then out and, you know, spread that message to their own local, you know, technical user base. So what we saw with AppU was little communities all over the world, actually. India and I think there was one in Australia. And so, obviously

we had one here in Dallas because I couldn't resist doing one here. But all over the place. When were you at that? I did not go only because Marshall gave a talk on Titanium like two days before. Oh, yeah. I gave at the Ruby talk at the Ruby Dev Chat.

But you did hit out some swag there at the Ruby talk, and I still support my AppU t-shirt at least once a week. Is this an ongoing program? If someone has a JavaScript or Ruby or Python meetup, can they get involved? As far as I know, we're still doing it. Whenever I go to the Mountain View office,

we just have boxes of the swag sitting around waiting for people to use it. I think it's awesome because I think we ran out of all that we had, and then we did a second order, and we're just waiting for people to use it now. Yeah, so it's pretty cool.

So are you just a committer on the desktop end, or are you also a consumer of Titanium Desktop? Well, so we have uh our main product which is how developers uh you know develop apps for titanium it's called titanium developer um and it's based it's a desktop app it's a it's a titanium desktop app so you know we we run through and test that pretty rigorously before each release so that's that's kind of our main app that we kind of eat our own dog food on. And we also have, obviously, a big test suite, which is a titanium desktop app,

and another test app which has manual UI testing in it. So I would say both. And for mobile, I don't technically contribute much. I've contributed a little, but mostly on kind of like the packaging side and whatnot. But I am developing, you know, a few just little personal mobile apps so that I can stay on top of everything that's going on there too. Any sweet spot that you think is best suited for apps of either persuasion?

You know, that's a good question. Well, people surprise me, to be honest. apps of either persuasion? That's a good question. Well, people surprise me, to be honest, what they come up with for doing this stuff. Because starting off, I think there are some pretty obvious use cases like brand applications, stuff kind of like the New York Times app or that sort of persuasion,

where there is content there and some interesting stuff there, but, you know, it's there to tie a person to a specific brand. But you also had things like, you know, people just porting more traditional desktop, cross-platform desktop apps to Titanium, or starting to. And we had some pretty interesting,, um, interesting, really, actually really interesting use cases coming out. Um, I can't talk about it right now, but, um, I'm hoping, I'm hoping that that'll be made public soon. Um, that, that's a really cool one. The one specific one I'm thinking of is really cool. Um, and then, you know, for mobile, um, kind of the same sort

of thing, you know, um, you know, Mark, uh know kind of like ad agencies will have like a specific brand they're trying to push and they'll make an app that you know has the content of that brand but also it's kind of you know a stylized brand it's like style application but we also have a lot of people who are doing like you know functional um like you know task oriented applications on mobile um right now and so there so there's a lot of variety, surprisingly, in what people are doing with it. I'm curious, actually, if you guys are hiring. That's a great question. I don't know if we're officially hiring at this moment.

We'll accept resumes, obviously. We keep them on the back burner. But as far as I know, I think right now we're just kind of holding steady until we can make some bigger announcements and hopefully expand the team at that time. We actually had somebody in the Twitter audience, a fellow by the name of, well, his Twitter handle is J-E-E-D-E-E. I guess it's G-D, right?

G-D. G-D. His question is if he wants to know if the titanium desktop is going to get some love and if you can give some details if possible. But he also made a special note to also tell you that titanium rocks. Thank you. Yeah, desktop is getting lots of love. For 08, so the 08 release that's out right now is mobile, obviously.

We've kind of lagged behind a little bit in desktop for the 0.8 release. We've had some pretty major things that we've been working on for this release. The two most notable things in this release are a brand-new Windows installer. We had one that we wrote kind of custom originally that didn't work out so well. It had some bugs. We received a lot of complaints kind of custom originally that didn't work out so well. It had some bugs. We received a lot of complaints from the community about that. So we revamped it, and we're using a newer style kind of MSI kind of native experience for that. So that was fairly substantial.

And then we're also supporting full dithering transparency now in your application in Windows, which is also supported before this in OS X. So what that means is you can do custom-shaped Windows and dithering out with partial transparency back to the desktop and things like that seamlessly with your web app. So pretty cool stuff. What are you guys using on the Mac side for updates? Sparkle or Homegrown or what?

It's all Homegrown. So we use the same code. It's all JavaScript-based. We use the same code on all three platforms for that. We actually have one thing we haven't talked about much is we have a cloud backend that actually more or less ties into your app. So when you develop an app using Titanium Developer,

you actually have kind of like an entry back in our cloud. And when you publish that app, we provide you with like, you know, a Bitly style link for that app, for like the downloads for that app. And you get your own analytics for that app. So you get like downloads and, you know, what platforms are used,

how many people from each platform are using it, things like that. And, you know, that all ties into our update service as well. So when you create a new release of your app, that update is pushed to your application via a JavaScript function callback. And then you can just handle that code however you please, but we also provide a URL which has the update in it. So a developer being kind of update in it. So, you know, a developer being

kind of like our flagship desktop app makes use of that as well. So whenever we make a new release of a developer, we push it through an old version of developer basically using developer to push new versions of developer out there. And the updates, you know,

get proliferated to anyone who has developer installed, which is all the titanium developers right now. So pretty cool. I know your primary focus is on the desktop, but on the mobile side, can you speak a little bit to what support you offer for the App Store on either platform, either iTunes or Android? We do have some integration with the process of going through and actually packaging the app up for the store.

But when it gets to the part of actually submitting it and whatnot, we kind of get out of the way at that point. So that's kind of your territory. So our tools for iPhones specifically at least, we have like a step-by-step wizard, more or less, or a step-by-step process that allows you to just kind of integrate your private key for your app, sign your app, all that stuff. It kind of walks you through a checklist. And then at that point, you know, we run everything through the simulator, you know, to test your app, obviously. And we also have integration with iTunes so that you can run your app directly onto the iPhone. You can copy it directly onto the iPhone. But we don't do anything yet for integration with Azure Publishing to the App Store.

And to put those applications on your iPhone, you'll need to enroll with the Apple developer program. Is that right? That's right, yeah. And it was my experience going through and doing that for a business was quite painful. And I believe the last time we spoke, you had mentioned that just to get up quickly, go ahead and do it as a personal account. And then if you have to do it for a business, do that in second step. Yeah, that's exactly what I did because it was really painless for me to do the personal account and obviously cheaper. I guess we're getting near to the point where we ask about stuff that's on your radar. So what out there in open sources is on a hot button for you?

What's on your radar? Node.js is really sweet. That's kind of the buzz right now in the JavaScript community. Serverside JavaScript apps have done really well, in my opinion. Just a really interesting API. I'm doing some really cool stuff there. The other open source stuff on my radar.

One that's not really new, but I think is really interesting is Raphael, which is doing vector-based animations in JavaScript. I think that's really awesome. And I think in general, the way that things are going, you know, we're going to be moving

to more and more complex graphic abilities in the browser and, you know, therefore in Titanium, obviously, as well. But I think some really cool things are going on right now in WebKit. They're implementing the WebGL stuff, which is all the three-dimensional APIs for the web. It's basically a lot like OpenGL.

And they've got that already in there for OS X, and they're working on it now for Windows. Some really cool stuff going on there. I've seen some of that stuff in action in JQtouch, right? Like with some of the various effects where you can cube a div. You actually take a div and turn it left and turn it right and it cubes. Is that what you're talking about? So that is what's called CSS 3D.

And we do have support for that as well. So CSS 3D is not quite like full three-dimensional like gaming quality 3D. So CSS 3D is like taking a two-dimensional object and being able to rotate it in 3D space. Whereas WebGL is a true 3D environment where you actually have

a three-dimensional scene and three-dimensional objects. So it's a lot like, it's basically OpenGL, more or less is what it is with a JavaScript API. So they're both cool technologies. They just serve different purposes.

I can imagine that the CSS one's probably not quite as robust as something that's done with JavaScript. Well, they're both JavaScript-based, but the CSS3D technique is mainly used for... How do I put this? So, like, when you first open Safari 4, you have this, like, it kind of looks like a mini bowl of webpages where, like, they have the different webpages that you recently visited. Oh, yeah, yeah, yeah. Yeah, and it's kind of, like, got a three-dimensional effect to it.

And that's done using CSS3D. So the idea, I guess, is like, you know, you can take two-dimensional content and kind of do some three-dimensional effects on it. And so that's really interesting in terms of like animations and like kind of stylizing content to make it look more rich and whatnot. Whereas WebGL is more kind of centric on, okay, we can make true three-dimensional things, and more or less, I mean, it's going to be hot for gaming, is more or less what it's going to be for at the end of the day.

But, you know, it'll have other uses outside of that too, I'm sure, but I think that's the main focus for it. What bearing, if any, do technologies like HTML5 and Canvas specifically have on either of these projects? Oh, on mobile and desktop? Right. I think huge. Well, I think huge because Canvas, like you said, is a big component of HTML5.

Right now, Canvas is mostly done with 2D graphics, but the WebGL allows it to do 3D graphics. So the Canvas is, I think, a really important piece of technology that's going to push web technology into the next generation. Being able to do things that traditionally you could only do with standalone, raw, low-level native apps. That's the way we're moving. I think within the next 10 years, it's going to be very hard to find low-level C-based games.

By the end of the decade, I think we're going to see a lot more higher-level. That's my opinion, anyway. I could be wrong. Well, 10 years is a long time, though. Web years. Last year was like 10 years ago, right? Absolutely. So we're talking about

100 years in web years thanks for that so next century we will so Marshall where can folks get a hold of you twitter github what not yeah so probably the best way is through twitter

or my email address I'm on twitter at Marshall my first name M-A-R-S-H-A-L-L underscore law, L-A-W. Um, and then, um, my accelerator email address is,

uh, M Culpepper. My last name, C-U-L, then a pepper like salt and pepper at accelerator.com. Um, and those are probably the best ways to get ahold of me. And then I'm also on the web at arcane.com. A-R-C-A-N-E-R.com.

Well, cool, man. Hey, we really loved having you on the show. Really appreciated getting a lot of your opinions on various things. The projects you're working on are super cool. Appreciate everything you've done for open source and everything Accelerator is doing for the community to, I guess, jump on board and do more with mobile. This is definitely pushing mobile into the next year it's going into, and I'm sure that, you know, Wynn and I were just talking about how location and crowdsourcing is in

every single app we're touching these days, and, you know, mobile plays a big piece in that too. So huge, huge piece in crowdsourcing, huge. Absolutely. Anything else, Wynn? No, that's it. Thanks again, Marshall, for joining us. You're welcome. Thanks for letting me talk about it.

No problem. Thank you for listening to this edition of The Change Log. Be sure to tune in weekly for what's fresh and new in open source. Also, visit thechangelog.com to follow along, subscribe to the feed, and more.

Thank you for listening.