Earlier this week Codaset.com, a software project management and code hosting site, officially left beta.  Joel Moss (@joelmoss), the creator of Codaset, agreed to answer some questions and absolutely carried this interview. 

Is there anyone else on the Codaset team?

Nope! Just little ole' me! I developed and designed everything you see and don't see.

What's your education and background?

I actually started out in sales straight from school, selling ads on the back of hospital appointment cards! I hated sales, and I was absolutely shit at it. But I manged to wing it for a few years until I discovered the internet. At that point I was hooked and taught myself how to build a site. That quickly turned into a $10,000 a month ad-supported business. But that was at the height of the dot-com boom, so didn't last too long. So I then turned to domain names and web hosting. I ran a successful web hosting business for 7 years, until I sold it a few years back. Since then I've been working freelance, and developing Codaset. I never completed any higher education, and am completely self taught, but I'm passionate about what I do, as I love doing what I do. I am very lucky that my job is my hobby.

What were the motivation and goals for this project when you first started?

I've used all sorts of source code and issue tracking tools in the past, but eventually settled on a mix of Trac and Github. Trac is probably one of the best open source bug tracking tools available, but is not particularly user friendly. It also doesn't support Git (not out of the box anyway). Github is great at source control and social coding, but their issue management leaves a lot to be desired. There is a reason why a lot of projects that are hosted on Github tend to go elsewhere for their bug tracking. Both of these tools are great at what they do, but that is usually just one thing. I got fed up with using several different tools. As Hannah Montana once said, I wanted the best of both worlds ;). And so Codaset was born. A software project management tool that I want, and that I use myself. Just this evening I deployed a small change to provide support for video embedding, simply because I needed to embed a Youtube video in a Codaset blog post.

What tools were used to make it happen?

The entire site is built with Ruby on Rails, with a selection of popular plugins. And obviously - as with Github - it revolves around Git. Data is stored in a MySQL database, and I wrote a bunch of other backend tools in Ruby. Ruby is definately my language of choice these days.

How long did it take to get where you are now? Did you take any funding on the way or is it entirely bootstrapped?

The idea really came to me in January of 2009, and I began coding it a month or two later. And if I remember rightly, I opened up a private beta sometime in August. And of course, it finally left beta just this past Monday (March 1st 2010). The entire project is bootstrapped, and to be honest, I'm not in this for the money. Codaset came out of a need that I had. An itch that needed scratching, and I'm loving it even now.

What type of success have you achieved to this point?

The project is still relatively unknown, although you can find Codaset on the official Git site http://git-scm.com/tools. The only mentions of Codaset have been on my blog (http://developwithstyle.com) and on Twitter. And that is pretty much how it will stay for the foreseeable future. I don't want to let this run away with itself, or for it to go too fast. Right now there are a little over 2000 registered users and they have created over 2000 projects. Maybe small, but I am really proud of that. I think my biggest success, has been how open I have kept the project. Yes, the code is all private, but from the start, Codaset's tickets have been completely public. Anyone can come along and create or update a ticket at any time. I use Codaset to build Codaset, which I think is brilliant. I've also tried to be as honest as I could, which has resulted in a few blog posts where lively discussions have taken place by the users of Codaset. And that is the best feedback any business owner could want.

Github is probably the most well known competitor. Name one reason that open source devs should use Codaset instead. What's the best argument to get a company to host use a private repo on Codaset over Github or their own setup?

As I already mentioned, Github is great at what they do, but they only do one thing great. Developers and designers have several projects that need more than just code hosting, and they don't want to visit or use several different tools to do that. That is just an avoidable inconvenience, and can also get very expensive. We want one tool for the job, and that is what Codaset aims to be.

Github has had some issues with downtime. What makes you confident that Codaset would be able to handle the growth if it receives the same type of interest?

Github has grown very fast, and I think that caught them by surprise, so they never had the right setup from the start. I was very aware of that when I started Codaset, so unusually for me, infrastructure has been one of my top priorities. Codaset was designed with scalability in mind. Whenever I need more space for git repos, all I have to do i plug in another server. And if I need the site to handle more traffic, again, I just need to add another server. The system has been designed to run across several different machines, and it is intelligent enough to recognise and work with that.

What is your plan to lure open source projects to Codaset? Do you have any ideas on how to market the site?

Open source or public projects will always be free on Codaset. I use open source software, and have contributed to several open source projects over the years, and love the open source community. So I don't want to charge you a penny to host and manage your open source projects at Codaset. Anyone can come along and create as many as they want. I also recognise the social aspect that Git and distributed source control encourages, so will be building on that in the coming months. I think developers have a natural desire to help other developers, and to be a part of a larger community. I want to help them with that.

As for marketing, I'm not going overboard as I need to stay in control. I'll keep blogging and tweeting, and talking about it to good people like yourself, and hope that it slowly builds from there.

Again, thanks to Joel.  I found his answers tremendously open and engaging.  I hope you take a few minutes to check out Codaset.com because it is amazing that one person could design and code that whole site.

If you missed part 1 you can check it out here.

From what I've seen the relationship between the maintainers of the top JavaScript frameworks is pretty friendly. How would characterize the relationship between the top PHP frameworks?

While there's been a fair bit of professional rivalry between different frameworks at different times, for the most part I'd say it's all in good fun. I've been fortunate enough to have met lead developers / prominent representatives from all the major PHP frameworks. They're all really great guys and I get along with all of them quite well, especially Paul M. Jones (of SolarPHP) and Matthew Weier O'Phinney (of Zend Framework). They're both very insightful, and I've never had an uninteresting conversation with either of them.

If you weren't the lead dev of CakePHP and Cake didn't exist what other framework would you be using (any language)?

Since we're going with any language, I'd have to say Node.js, which is (wait for it...) a JavaScript framework. I've always loved JavaScript, and it's probably the only language that would tempt me away from PHP for server-side development.

Do you get to code Cake apps at your day job? Are you able to work on the Cake core during the day or do you do everything off hours.

Well, my current job is with a startup, Hoopla Software, and I'm developing an app on Cake 1.3 that talks to SalesForce. I even wrote a database driver that speaks SalesForce SQL, which we plan on releasing later on. At my previous job with OmniTI, I'd say about 50% of my projects were in Cake. In both cases, work on the core itself usually happens in conjunction with something specifically work-related, with the occasional quick bugfix during the day. Both my current and previous employer are very supportive of Open Source, so I've been fortunate in that regard.

Favorite coding beverage during the day? for after hours?

I'd have to go with Coke for both. I was recently introduced to a drink called Club-Mate in Germany, but that stuff is dangerously powerful.

Favorite music to code to?

Well, I don't really have a favorite, and my musical tastes are pretty varied, so this list could go on for a while. Some of the highlights: The Who, Switchfoot, G. Love, The Police, Weezer, Bowie, The Beatles, Simon & Garfunkel, Guster, Jet, Sinatra, Death Cab, Café Tacuba, Cheap Trick, Cake (!), U2, Peter Gabriel, Relient K, The Proclaimers, The Caesars, The Specials, The Cure, Citizen Cope, Sanctus Real, Bob Marley, Elvis Costello, more Switchfoot, and Garrett's favorite: Oasis.

What apps have you built using the CakePHP framework?

Besides the one I'm working on right now, most of what I've worked on I'm not technically supposed to discuss, particularly not in print (see! if you were at CakeFest, you'd have heard the stories). In very general terms, I've written a tool related to security testing, a very big and high-profile tracking tool for a company that everybody's heard of, a bunch of smaller sites and tools around a database and suite of analytics tools for helping political campaigns analyze several terabytes of voter data, a portal for a football magazine, a couple of smaller, more personal CMS-y type stuff, mainly for the heck of it, a very JavaScript-heavy calendar app with iCal syncing, and a couple dozen smaller for-fun side-projects, most of which will probably never see the light of day.

Aside from those projects, on which I've been the principal developer (or one of), I've had my hands in or on several other CakePHP projects (and non-Cake / non-PHP projects), public, private and Open Source.

The End

Thanks to Nate for being so open and giving some awesome answers. I will now freeze myself, Cartman stlye, rather then endure the wait for Cake3. Someone please remember to dig me out when it's released.

Intro

Yeah, yeah, I know. This has been done before. What can I say - I had questions, Nate had answers. This is part one and covers general Cake and Cake3 questions. Look for part two tomorrow, which has a bunch of random questions.

General Cake Questions

The end game looks like there will be three CakePHP versions, which can be confusing to new developers. I haven't seen this explicitly defined, so stop me if I'm wrong:
The 1.3 branch is for anyone developing for PHP4
The v2 branch is for anyone developing new projects for PHP5-5.2 OR for PHP 5.3 users looking for an easier upgrade for a 1.2 app.
The v3 branch is for 5.3 apps.

That's about right. Once the 1.3 branch goes stable, that'll close off principle development on the 1.x branch, barring bug and security fixes and so forth. We haven't completely ruled out the possibility of back-porting future 2.x features, but that will largely depend on demand, which at this point we don't expect; and yes, 2.0 should be a direct upgrade from 1.3 (which has very few API changes from 1.2). 3.0, on the other hand, is still under pretty heavy development, so it isn't recommended for anything other than experimental applications just yet.

How many people are actively contributing to the three new versions of Cake. Whats the breakdown in terms of # of developers working on each branch or does everyone work a bit on each branch?

Well, in total I think we have something like 16 active team members working on various different things, including things other than the code itself. 1.3 has had about a half-dozen active developers, with the bulk of the work being done by the Canuckistani dream team: Mark Story and Joël Perras. In order to manage the extra work, Larry has brought in a few developers from the Cake Development Corporation to help out on the 2.x branch, particularly Graham Weldon (a.k.a. Predominant) who's been doing a lot of the heavy lifting to get the current code base fully strict-mode compatible.

Finally, I'm leading development on the 3.0 branch, with Joël, Garrett, David Persson, and Tim & Felix (of Debuggable) contributing.

Cake3 Questions

Right now 1.3 and 2 are still licensed as MIT. Cake3 is BSD licensed (although some files are still MIT (stuff in app) and the license.txt file doesn't specify any particular license). Whats the deal with the change? How will this affect developers?

Practically speaking, this won't affect developers at all. In terms of what you can do with the software, the BSD license is just as permissive if not more so than MIT. The change was mainly due to my own personal preference: the BSD is an older license with a more distinguished Open Source history. Garrett was also very supportive of the change, as the BSD license includes a specific clause that shields the CakePHP brand and the CSF from being abused for commercial purposes, which we've always been very much against. We're really excited to see people building businesses off of the code we write, but people using our name to promote themselves is just not in the spirit of what we're trying to do.

As for the places where the MIT license still appears, that's just some cleaning up we have left to do from the old CakePHP distribution. It'll be all BSD all the time before a release goes out.

Cake3 is switching to returning objects for result sets instead of array. I'm probably remembering wrong, but I thought you preferred the array approach. Was this change something need to be convinced about or was it something planned all along.

Well, that's close. My position was always that I preferred the array approach in context. Since the context at the time was PHP4, and PHP4 had all the array-hacking functions you could ever hope for and a crippled object model, it was the natural choice. Now that we've progressed beyond that, there's just no need to stick with arrays anymore, which I'm all for, as it frees us from a lot of the restrictions we had on how we design things.

Was there anything that came from the google group "hate" thread that you hadn't planned to implement or prefer a different approach, but were swayed by the community?

Probably my biggest reversal of position (and this is in general, not only regarding the 'hate' thread) has been regarding multi-column key support. The thing about single-column keys is that they make things consistent and easy all the way up and down the stack (REST APIs, etc.), and that's great. But what I realize is that there are often (again, in context) some good arguments for using multi-column keys, and even if we don't support them at higher levels, this is something that any well-designed data abstraction layer should support.

Say I'm a pretty good developer, whose willing to dig through code, submit patches for bugs and I'm starting a project that won't be launched for at least a year. Would I be crazy to start that project in Cake3 right now?

Well, it depends on the app. For most things, I'd say it'd be a pretty big commitment, since right now a lot of basic things like pagination and session handling are still missing. A lot of that doesn't matter though, since with Cake's new structure, you can load in other classes and libraries fairly easily, eventually including things like using Doctrine in place of the default ORM. Also, a lot of the API should be pretty familiar to you if you're already a Cake developer, and much of that is unlikely to change.

If anyone has a really experimental app in the works and would like to contribute to the 3.0 branch, I'd be interesting in talking with them about contributing. The biggest thing that this new version has going for it is that the plugin architecture is already pretty well-developed, and plugins are handled in almost exactly the same way as an app, and even the core itself, so everything is very interchangeable. Another major architectural difference is that most class dependencies in the core can be swapped out for classes in a plugin or in your app.

What we're hoping to achieve with this is that once the core becomes more stabilized, all the interesting development can happen in plugins. This is really important, because the barrier to entry on contributing to a smaller project with a more constrained feature set is much lower. Development can happen in parallel, and features can be moved in and out of the core distribution with relatively little impact on application code.

What's going on with unit testing in Cake3? It looks like SimpleTest is being dropped and instead Cake3 will have it's own unit test tools.

Again, this is one of those decisions which was made for us previously, as SimpleTest was the only viable option for PHP4, short of writing our own test suite, which we've decided to bite the bullet on this time around. Several factors went into that decision, but mainly (a) that we wanted people to be able to run tests right out of the box, and (b) we wanted a testing infrastructure that was tailored to our needs and allowed us to measure things in a way that we wanted; things that would help people judge the quality of software distributions. Not just Cake itself, but plugins and applications. I'll be talking more about this later on.

However, we plan to keep our test suite fairly lightweight, and one thing that'll be revisited before a release is the API; specifically bringing it more in-line with PHPUnit, to streamline the upgrade process for those with more heavy-duty testing needs.

The filter system looks pretty sweet and has been talked about a bit. What Cake3 feature are you most excited about that hasn't received much attention?

At this point, I guess the biggest thing that I haven't talked very much about yet is the Media class. The Media class is interesting because it takes out a lot of the work that was previously required when serving or handling different content types. It sits between the controller and view layers, and allows you to attach different handlers for each content type, both input and output. This means that instead of having to create a view every time you want a controller method to render as JSON, you can just attach one handler, once, that tells all JSON responses to automatically assemble themselves from the variables you set in the controller. For HTML on the other hand, a view class is attached (by default) that works as normal, rendering templates from your views/ directory as normal; but even with in that there's an incredible amount of flexibility, and you now have one place to configure it, application-wide.

I'm still a little confused about how filters work. You tie a filter to a method, but don't have to specify if it's a "before" or "after" filter, right? If you want it to act as "before" you just run your code before calling return $chain->next(...). How would you do an after filter? Like this?

$ret = $chain->next($self, $params, $chain);
//my code
return $ret;

Yup, that's exactly right. You can think of writing a filter a lot like you'd think of overriding a method in a subclass, but instead of calling the parent method (i.e. $result = parent::methodName()), you're calling $chain->next(...). This has a lot of notable advantages over simple before and after filter methods, probably the biggest being that all related operations are kept together in the same scope. Not having to split things up between two methods means you don't have to worry about persisting things through parameters or object state (or worse, global state). Everything is neatly atomic and isolated. It also makes a lot more sense when you're browsing through code.

To Be Continued...

More from Nate tomorrow when we cover what music he codes to and much more. I bet you just can't wait for that.