The Changelog: Software Development, Open Source - Serve, RadiantCMS, Design and Prototyping (Interview)

Episode Date: March 16, 2011

Adam sat down with Designer/Developer John Long, creator of RadiantCMS about his new project Serve, design, and running a successful open source project.

Welcome to the ChangeLog episode 0.5.2. I'm Adam Stachowiak. And I'm Winn Netherland. This is the ChangeLog. We cover what's fresh and new in the world of open source. If you found us on iTunes, we're also on the web at thechangelog.com. We're also up on GitHub. Head to github.com slash explore. You'll find some training repos, some feature repos from the blog, as well as our audio podcasts. If you're on Twitter, follow Change Log Show, Change Log Jobs, and me, Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N.

This episode is sponsored by GetUpJobs. Head to thechangelog.com slash jobs to get started. If you'd like us to feature your job on this show, select advertise on the changelog when posting your job, and we'll take care of the rest. Our friend Zencoder, a startup focused on tools and services for video website developers. It's looking for a smart person who is also a Ruby and Rails engineer.

Perks include stock options and a growing startup, relocation assistance to the Bay Area, and freedom. They trust you. Check it out at lg.gd.com. And our friends over at Store Envy, the Tumblr for e-commerce, are looking for a lead champion of codes, a Rails engineer, and a president of beautiful things, a UI designer. Both are full-time positions, and based on a recent tweet, they're offering a 5K bonus. Check it out at lg.gd slash 9h and 9i. That would be our buddy John Crawford, who I ran into down at South by Southwest. We had a fun time in Austin.

Bailed a little early on the conference, but had to get back to some work stuff. But handed out a lot of stickers, met a lot of fans of the show, got to meet a lot of you in person. Some fun times down there, but I understand you had some fun times back home, interviewing John Long from Serve. Yeah, I went solo and I talked to John Long of

Radiant and Serve fame. We covered all things Radiant, the community, optimism and open source. We also talked a little bit about website prototyping with Serve, which is pretty awesome, and I hear you guys use it at HP. We do. I'm anxious to hear this episode because if you're building a Rails application and you've looked at Static Manic or some other prototyping tools,

take a look at Serve because it's by far the easiest drop-in replacement once you actually get to your Rails application. It's just the view layer that you can just snap right in there. Yeah, the server is awesome. It's perfect for those who love those common Rails front-end tools like Haml, Sass, and Compass. It's pretty easy to deploy to Heroku, but a simple brochure or website. It's production-ready, so it can deploy to Heroku. It's really, really awesome.

You guys also talked about Radiant and some of the backstory. Yeah, a lot about the first Ruby CMS. We also talked about John's stint into design and how he got involved with the RubyLang website and what that led to for Serve. Sorry, I guess ultimately it was Serve because Serve kind of came from Radiant, but it was really the kickstart for Radiant. Fun episode. Should we get to it? Let's do it.

I'm joined today by John Long, proprietor of Wiseheart Design. I'm running the show solo today. So John's with me. He's the creator of Radiant CMS. We're going to talk about this and a lot of fun front-end developer stuff in this wild world of open source. But John, how are you today? Doing well.

So John, for the folks who do not know who you are, I don't know why they wouldn't, but why don't you give a brief introduction about who you are and what you've been up to. Okay. I do freelance design work. I've been doing it for a number of years now. And I guess at the beginning of my freelance career, I was from that. And for Ruby Lang, I also created Radiant CMS, which is a content management system that is well-known in the Rails world. So, yeah, that's who I am. I live at home. I have a dog, Lily. Yeah.

Very cool. Well, that's actually how I know you from back in the day, and I love the design that you did for the Ruby website. It's definitely awesome, but I didn't know that Radiant came out of that project. What was that like? That was at a point in my life where I was really optimistic

about the value of open source contributions in the sense that I actually took about six months and programmed Radiant CMS. So I moved back and I thought, I want to do freelance stuff. So what would be better than like to have a content management system that you wrote for websites? You know, so I yeah, it was it was kind of like. Doing my own little startup that was kind of open source aims, I guess. And, yeah, during that year, launched Radiant. It ended up kind of paying off. I made contact with the Pragmatic programmers through that experience and was able to do some work for them,

which was another great sort of portfolio piece but as I look back on it probably wasn't the best way to start a freelance career I guess but developing a CMS you mean yeah well I mean I haven't actually ended up doing a lot of websites that are CMS-focused kind of thing. In my other job, we had done a lot of content management stuff, but that wasn't where I ended up carving out my little niche. I ended up more in the web app space rather than the website space. And Radiant's much more in the website space. So it's interesting.

So when you actually picked up the idea of the CMS, were you starting to work on Ruby Lang or was this a product that kind of started in parallel with it for a niche or a need that they needed? Well, at the time Rails had just kind of come out and Ruby Lang was, let's see, how did that all work? I was working in Chicago and at a certain point I was just like, man, the Ruby website is just really bad. I mean, it's very, like it used a lot of red in the header and different things like that. Red everywhere, red and pink. And it was hard to read.

It was basically just a blog. And I was getting to use Ruby at work as a developer and just felt like it needed something better. So I sent a post out to the mailing list and suggested that we form an identity team, much like the Mozilla Firefox identity team, which had just had great success in designing the Firefox icon and all those kinds of things. And the idea caught on and I ended up getting to be part of that team. We did the design and everything. We got all of that rolling. And then it was like, well, how are we going to deploy this thing? And why the lucky stiff was actually on the Ruby identity team at the time. And he gave a go at it using, he like a precursor to maybe Jekyll. It like generated and then I don't know if it FTP things over how it works exactly, but you ran it on your local box and we gave it a go with that and it like didn't work for what we were trying to do. So we were stuck with a lot of, I guess, Ruby-like solutions that just weren't really well done. And I had had some experience at my old job doing a text pattern site. I had written a custom... We used a lot of RHTML running on

mod Ruby, so it was really more akin to PHP or something like that because it was just ERB plus some custom classes that we had written. And so I had written kind of a templating system around that and was real intimidated over what I thought should be in a content management system. I saw that Rails was there and I thought, wow, I could just spend some time, a couple of months, hack this thing together. And so I kind of made a commitment to do it.

And it was sort of like once it was out of my mouth, I had to do it. And I don't think I really anticipated it was going to take like six months to do the major development on Radiant, or five months or something like that. But we were able to get that done, launch the Ruby website successfully. I think it ended up being around August by the time we had launched the Ruby website successfully. I think it ended up being around August by the time we had all the pieces in place. They had to do like a server upgrade so that it could run Rails and some different things like that. And so what was it that actually took Radiant to become, I guess, more of the more mainstream Ruby CMS available out there?

I mean, it was the first. And I think that being the first and also being... Well, we made a commitment kind of early on. David, the way that he talked about rails and the continued development and all those types of things, what rails was going to be and what it wasn, drinking the Kool-Aid, not breathing it. Yeah, exactly. And I was like, yes, yes, Radiant is going to just be focused on this one area. And the way that I'm going to serve those other things is I'm going to do a plug-in system from the beginning.

And having made that commitment after Luchy Radiant, it took like several more months to build the plug-in system for it. And I think I ended up writing the basic idea for it. And Sean Cribbs, at a certain point, started working on something he called Shards, which was a way of allowing programmers to declare where certain partials should be included in views. So you could monkey patch to insert controllers and things like that that you needed to, but Shards allowed you to make modifications to the view so that two plug-ins that overrode the same view wouldn't conflict.

Instead, you could plug in pieces into the view instead of overriding. So, yeah, it kind of grew like that. And once we had the plug-in system in place, it really sort of developed on its own. And since maybe the first eight months or so, there's been like just a group of people using it and developing stuff for it. We've done different things since then. We've got an extension registry with like over,

there's over 200 plugins for it. But because there's kind of this ecosystem there, even though I feel like there's, we're still learning a lot about, and frankly, just we don't have enough time to make Radiant what we want it to be, what we know it can be. Even though it's still green in some ways, there's a lot of people that are passionate about using it and enjoy it. So it's really the community that kind of formed around it. And it required a lot of effort in the beginning.

I don't think that I could have launched Radiant kind of successfully if I hadn't been pretty devoted to it in the beginning. But it's become sort of a self-sustaining community to where now I'm... I turned over the lead development to Sean Cribs. At one point, Sean has gone on. Jim Gay has taken up that mantle.

We've got several people that are on the core team. I mean, I really feel like I could step out of the picture and it would still, you know, continue to go. I haven't done that yet because I still have vision for where the product can go, and we haven't totally achieved what I was wanting to achieve with the product when we first introduced it. But I think that's the community itself is the main reason that Radiant has done so well in terms of being that go-to CMS within the Rails community. There are certainly other content management systems now, and I'm not real aware of the communities that are around those,

but it still seems that Radiant, it's the community that kind of holds it all together. So when you look at Radiant and what it is now, but you said a couple times there what you still have vision for, what is the vision in comparison to where it is now and where you'd like to see Radiant, whether you're part of the team or not? Yeah, I think for me a big sort of part of this is seeing it be able to compete head-to-head with tools like WordPress, particularly on a usability level.

I feel like we have some ground to cover there. Some of it, too, is just getting good pieces in place to handle, like, the asset management side of it and different things of that nature. Part of the push with the asset management... Asset management still hasn't made it into core. And one of the big development efforts right now is that we're going to begin launching into, particularly as we move to Rails 3, is dividing up the core so that different

parts are easy to take out. And once we have that kind of design in place, it'll be easier to have like a default asset management solution that if you'd like a different approach, you can plug in that different approach and it would still like work with the rest of the system. So some of that has to do with we've been working through the best way to build a modular plugin-type architecture within Rails. So there's a piece there and then there's a piece with just the usability, the friendliness of it.

I've actually been using WordPress a lot on one of our church's websites, and it definitely has... It's a lot more user-friendly to the end user. Radiant is a whole lot more powerful in terms of what it allows you to do with the code, which is where it's really fun to use. But it's still got a ways to go in terms of competing with something like WordPress head to head. So WordPress is more of a user-friendly kind of GUI kind of scenario where you can also

still develop plugins, but it seems like Radian is more of a hacker CMS, mostly that, like you said, underneath the code, you can really dive in and do a lot more with it. Is that about the case? Yeah. I mean, just for instance, the macro language that Radian uses for its templates, Radius, is accessible throughout

the system, whether you're on a page or you're in a layout or we've also got a concept calling Partials to become snippets. So you can use the macro language wherever you are. And part of Radiant's sort of ethos is that the idea that, like Ruby, we want it to be a system that provides a tremendous level of power, but it's very accessible to people that are coming on board and learning. So even though you might discover a page that has radius tags in it, for instance, if you're just a content editor, you can go in and make changes relatively easily with only understanding like markdown or textile, something like that. So there definitely is a lot more, I guess you could say, raw power in what Radiant allows you to do out of the box, but it's still not as user-friendly to the end user. And so as we continue to develop the interface,

I saw you had a blog post about having more design savviness in it, and you were doing some prototyping with the navigation and whatnot. How do you get more designers involved to not only make Radiant an awesome CMS from a backend standpoint, how you have asset management and ease of deployment and those kinds of scenarios, but how do you also design this interface in an open source community that makes sense? Yeah, I mean, that's really kind of an open question. It's the one area of Radiant that I have not been able to completely relinquish to someone else being the design piece of it. And it's something that we're experimenting with. One of the things that we're doing is we have a separate project where all the HTML development takes place.

We actually use Serve for that. And the idea being that a designer wouldn't have to understand Rails and all those things in order to contribute. You could just download the prototype project, say I've got this idea for something, and work it on GitHub or whatever,

and then everybody would be able to download it and check it out and see what it looked like before it went into development kind of thing. So, I think part of it for us... WordPress has definitely gotten a lot more exposure, for instance, and there's a lot of designers who use it. And so, they have had more input into the design itself from the community.

And the Radiant community is not that big yet in the same sense. So I think that part of it's just we haven't gotten to a point where we have a lot of designers that have spare cycles and want to contribute to the way that the CMS works. And part of it is we need to do a better job of bringing those people into the community, I guess. And still experimenting with different approaches and how design can take place in more of a collaborative kind of way. I think that's really difficult in this source world. I mean, if you're just a, let's just say a designer, not so much someone who dabbles in a lot of the code, maybe you're just the designer piece of it,

or maybe you're dabbling more into HTML prototyping, but you're not using tools like Camel, SAS, Compass. You're still kind of on the actual language itself, HTML and CSS. And then you enter this world of Git and GitHub, and it gets a little intensive, and now you've been introduced to the command line, if that's never been a place for you before. So it can be kind of hard to jump into these environments and use your true skills in this unusual world.

Yeah. true skills in this unusual world. Yeah, I mean, I think for sure, and particularly Rails is not an easy environment for a designer who doesn't know a lot to jump in and work with. I mean, when you compare it to stuff like WordPress and so many people out there that are using WordPress and don't know anything about AML or SAS or Git. They FTP the thing over to their server. FTP? Yeah, FTP. Who does that anymore? Most of the world does. Rails is awesome, but it's a foreign language to so many people.

If they're using FTP, they must not be even using any version control systems either. So just thinking Git, they're thinking, what about the version of my code? That doesn't make any sense. Yeah, I mean, getting a theme and just making modifications, you know the story. You make a change and you call index.old.html and all of that type stuff.

Your version and the actual ways you rename the files and whatnot, and then you even have an old directory above it so that you can put those old files after they've cluttered the file system that you're trying to mess with. So speaking of the designers and trying to prototype, you mentioned Serv as part of Radiant

and you use Serv to actually prototype the interface for Radiant. Looking also at Radiant, I see a lot of similarities in how you list pages and how that hierarchy kind of gets displayed in that UI. And in serve, it's more of like right there in TextMate. Was that just a natural extraction from the result of building a lot of content-heavy sites at my old job. And I began to think in terms of like a hierarchy of pages, and that was something that I was

at the time really frustrated with about a lot of CMSs. Does WordPress allow you to arrange things in a hierarchy now? I don't use it enough to know, but I think they have a pretty okay UI. I think you can order the pages, I think. Yeah, I think they use kind of a concept of menus, but maybe the pages are all flat or something. I'm not sure how it works exactly, but I know that when I was working on Radiant in particular, I was really wanting it to be something that kind of

reflected that concept of the URL and content being structured underneath URLs. And in a very similar way to the way that it works on the actual file system. So when I was working on Serve, a lot of the same concepts sort of fell out in that regard. So before we dive too deeply into talking about CERV and what it is, let's let the listeners actually know what CERV is. So a rating is a CMS. It's deployed. It's got a UI. It's got a whole different deploy structure. But what is CERV in comparison?

So at its smallest, CERV is a rack-based web server for files. It handles ERV, Haml, SAS. You can integrate Compass into it. So that's kind of the technical, like, what it is, being a web server. It's also, or the way that I would describe it is it's a rapid prototyping framework for web applications, and specifically Rails applications. And what I mean by that is that Rails applications have your model, your view, your controller, and serve is basically like having a Rails application without the models and the controllers. You just have the views. So as a designer, if that's the part that

you mostly work on, that serve allows you to just focus on the views without having to build out or have built out for you the other components, the models and the controller. So you're able to prototype what you want the application to be in HTML and CSS without worrying about how the back end can run and all that kind of stuff. Yeah. And so prototyping, this is obviously a fun thing anyways because I know that as a front end developer designer in the Rails slash Ruby world, trying

to iterate and trying to prototype before was always a pain in the butt. And now that I know about Serve, my life is so much happier now. Just being able to easily pick up a project with all my fun tools in it and build it out based on URLs and all that good stuff. So URL-based design, it seems like in Serve you pay a lot of attention to that. You have this notion of redirects. What are some other cool features that the listeners should know about for Serve? Well, in regards to URLs, one of the things that Serve does is, like some web servers do or can be set up to do, by default, it allows you to append a slash to a file name without the extension in order to get a slash-based URL instead of a URL that ends in an extension. So one advantage to it when you compare it to like normal HTML is that it actually allows you to begin to prototype those URLs in addition

to the HTML that you're going to want for the application. It does have redirects, a very simple syntax there. You just open up an empty file with an extension redirect on it and put the URL in that you want to redirect to, and then it will redirect over to that other URL. And that's handy because there's a lot of times when you're programming or doing an application and you want there to be kind of a create action or something of that nature that creates and then redirects to a new URL. So having the ability to put a redirect in the place of where that action will be is helpful. You can also do email templates for text-based emails for prototyping that aspect, which gets sent out from the server. And it's not that you couldn't just have a text file or something like that, but SERV's got it in

place so that you can put the headers that you want on that email. It just renders in the browser as HTML, but it would allow you to kind of specify specs for the developer. You know, this is the address that I want it to be sent from. This is what the subject should be. This is the text of the email, the URL, that kind of thing. So there's just a number of aspects that are particularly familiar to Rails developers that Serves tries to make easy for the designer to give hints to the developer as to how the application should work. And so do you also have tie-ins to helpers

and other tools that link to, and you've got a number of different helpers there that are just kind of baked into normal Rails, so porting your view code is pretty seamless. Yes. We do have a number of the really common view helpers from Rails. Link to, you have access to the request and the response params, a couple of text massaging ones for like escaping stuff, that kind of thing. And then you can also put your own view helpers in a module and those would get imported into

the application. And what's interesting about that, if you're a designer and you're working on an application and occasionally you want to write something to make it, you know a little bit about Ruby, but maybe not a whole lot, and you want to write something to sort of indicate a certain output or something like that, you throw it in a view helper, then the developer has that as a guide

as he pulls it into the application. And your view helper could be completely stubbed out and that it returns the same response every single time. But then the developer would go in and each actually make it work with rip data or whatever it is. And there's a nice decoupling essentially between what the designer is kind of focused on and what the developer can be focused on in the back end because the developer can also come in and put in some common view helpers to allow

the designer to be more flexible in the way that he's designing. But it doesn't have to be the same as what's currently in the application, I guess. So they can work a little bit more independently, the designer and the developer. Sometimes if you're working in a Rails application as a designer, you can change one line of code and it messes up something unintentionally.

So it's a little bit more guarded when you're working in your own space, which is a really nice aspect of Serv. So as a user of Serv, what are some of the fun things that you like best about it, and what are some of the fun ways that you use it? I really love prototyping in general as it relates

to applications, and particularly having the ability to do layouts and partials in that Ruby-friendly way that I love about Rails view templates. I think that's where a lot of the early applications I worked on sitting down with a client and we were working through the application and I had a layout designed for the application and we were like, what should go on this screen? What should the fields be? And he would tell me, and I would just type inputs in,

and it just came alive, like before our eyes kind of thing. So I already had some styles in there. And because I wasn't actually working with, like, static HTML files or something like that, there wasn't a lot of code that I had to write in order to prototype the idea of something. And I went back later after that time with the client and was able to dress up the forms a little bit, change the style, a couple of things. But just being able to capture that really rapidly, right in front of the client's eyes,

what they were thinking should go on that page kind of thing was really, really helpful. And that project itself went through... We actually went back and redesigned the look and feel of it, and that was a matter of swapping in a new layout, and it all flowed and worked in the separate prototype application. So I think the maintenance of your HTML mockups is probably the biggest thing that I like about Serve, in that it cleans that up, it allows me to use the patterns that I'm familiar with in Rails, but I'm not working directly in the Rails space either, so I'm not getting in the way of

the developer making the changes. It allows me to be a lot more conceptual, I think, in the sense of just sort of dreaming about what a feature should do instead of being worried, I need another controller here, that kind of thing. And actually, because I do both design and development, that's almost needed for there to be that separation, because I begin thinking too much about the back end, and pretty soon I've lost time where I should have just been writing HTML and CSS. Right, you probably generate a controller, and next thing you know, you're writing out

the view code in your controller and whatnot and then dropping it to the view instead of actually crafting the UI and thinking about that. Yeah. Kind of keeps you focused. And I mean, I work with a lot of web applications and we make changes, significant changes at times. And if I was having to think about or adjust the way the controllers worked and all that kind of thing, just to prototype out a new way of doing something, there's times when we decide not to go down that path,

not to spend the money to develop that feature that way. And because we're able to prototype it in HTML, get the feel for the flow, get the feel for the features, the way the feature is actually going to work, we don't end up having to spend those dollars on the development at that stage, too. Or even a separate branch that somehow gets merged and it's who kind of the mess

that causes right that's uh that's that tends to be the road that i'm in i end up being on a team and somehow i end up in my own redesign branch and i'm like the only person there i'm like the designer in the front end doing all the prototyping that you're talking about and i've got devs and in other corners of the of the get repo that are doing their own thing and it's like at what point do we merge and and what kind of havoc is this going to cause yeah and i mean you probably have to get somebody when you're in that situation to come like sit by you while you do the merge or whatever yeah you're kind of scared to do it yeah i was like i don't want to merge this branch because I don't know what's going to happen. Yeah, I always feel a little bit guilty

when I do that kind of stuff because I'm not in the code all the time and I just know that I'm going to break something unintentionally and then the developer is going to come back and be upset. I've had the good fortune of working with really nice developers, but it's still like, what am I going to do here? I appreciate Serve a lot from that perspective. It's my world.

I can feel free to break things as I'm moving stuff around, and it's not a big deal. So we talked about Serve as a rack app. We also talked about it being heavily guarded for prototyping. But what happens when your prototype graduates? Let's say you're not building a Rails app. You're just building a UI in general, just let's say a brochure website or a light website with maybe 15 pages, 10 pages, something like that, that isn't very dynamic. It's pretty static.

And what do you do when that kind of application grows up? Well, I mean, it is a rack application service, so you can deploy it just like you can any other rack application, which means you can deploy it on Heroku or whatever Ruby host you like. So it is useful that way. You can also use things like Rack Cascade with a Rails application, for instance, running on Rack to cascade.

If the application itself doesn't have that URL, then it goes to the serve application to fetch that content, essentially. So there's some nice, because it is a RAC app, there's some really nice things that you can do in terms of integrating it with existing stuff or running it on its own at a different place. I almost see serve as kind of like the perfect pages control that I've always wanted in my Rails app. And it's almost kind of you want to see the two play hand in hand because you have this Rails app that has got a full backend, but you also have this lightweight marketing slash brochure website on the front of it to pin up to. But how do you build those in a normal MVC kind of schema in a Rails app?

Yeah, I think that there's actually some room there for serve to grow. It would be great one day to be able to share layouts between your serve application and your Rails application without a lot of work. There actually is some old, crusty code in there, I think, that ran on Rails 2 that allows you to... Yeah, you could mix in to a controller in Rails to serve functionality, basically. And then it would become your page controller and have access to the same things that Rails does. It hasn't been worked on in a while.

It probably would break if you tried it. Oh, boy. Yeah. Well, you mentioned that when you tackled the Grand project, which was Radiant back in 06, that you kind of felt like you were trying to really tackle something big. But then not long ago, you started a project called Acoustic, which intends to kind of bridge the gap between a Ruby slash

natural world and maybe even kind of bring some of the things we know about in Django and Rails into a more lightweight Ruby web framework. What is Acoustic? What is this about? Yeah, this is really, Acoustic is sort of my, like, pipe um web framework kind of thing um it's it's one of those things that i almost feel like foolish working on because like everybody has rails is such an awesome framework and sinatra is amazing that's small stuff like there's a room for anything else kind of thing and I feel like Rails has come a long way in terms of modularity particularly with Rails 3 but it still seems really heavy at times

and I've written a little bit about this on my blog. I wrote a post, what Rails could learn from Django, different things like that. And really trying to remove maybe the number of files that you have to create in order to work within the application, give you more flexibility in terms of where things are. One of the things that Acoustic allows you to do is have your controllers and your views all in the same directory. So what's the advantage of that? Well, if you're trying to structure something in a modular way, you could essentially have a part of the application that was like a Git submodule

because you're able to have just that folder, those controllers, those views, all of that in a separate repository. So Acoustic, its aim is to be maybe a more modular Rails-type framework, but it's still very much a toy. It's not fully implemented in any way. You couldn't download Acoustic and run anything on it right now. It's got a router in it. It's got a basic controller structure, but I'm still building out like major portions of functionality. And so, and it's really right now, it's kind of a back burner project. The hope with it would be that maybe it would either someone would adopt it and it would become something real or that it would influence the design of stuff like Rails maybe eventually. You mentioned earlier in the call, really early in the call, that you were highly optimistic about open source back

in the day when you were starting to work with Ruby Lang on the redesign and Radiant. Has your focus changed towards being highly optimistic because you just said that you hope that it kind of influences or maybe somebody adopts it and assumes that the open source world is just... Yeah, that's kind of optimistic. It's got three watchers. Yeah. It assumes that the open source world is just, yeah, that's kind of optimistic.

It's got three watchers. Yeah. Well, I am very optimistic about open source in general. I guess what I meant in reference to that was that open source is valuable to, extremely valuable to the person who is starting a freelance business. And the thing that I learned is that, yes, it can be, but it can also be, it can sort of take over your life, which is what it did with me and Radiant for a number of months. I was committed to not letting

our question go unanswered on the mailing list and things like that. And it just, you know, I couldn't have done it if I wasn't living at home with my parents at the time kind of thing. So I think that when I say I was really optimistic about open source back then, I was really optimistic that it was going to bring in business and let me do some cool things. And I feel like I was fortunate to get the projects and things that I did, and some of it was a result of my open source work, but my time could have probably been spent way better, even just cold calling people, offering my services than working on a open source product for six months. But I'm glad I did it too. I mean,

it was a great experience. So I don't know. It's just more in terms of thinking about where I put my energy in and all of that kind of stuff in the future, I'm much more aware of the effort that it takes to run a successful open source project. And maybe I'm a little more jaded than I should be about that as a result of working on something that's kind of as large as Radiant. But yeah, that's kind of what I meant. Yeah, I know that Radiant has done really well, and it's got a huge community. I mean, you even got your own GitHub group to manage that.

And I think inside of that group, you've got, you know, 49 members of that group. You've got 39 repos in that group. So obviously we should be optimistic about open source and you did a great job with leading this and starting this. But speaking towards the community that's prompted around Radiant, what were some of the things that you think you and the community did right to enforce and help elevate and provide support to the Radiant community and Radiant as a project? I think the early success of Radiant was the result of the plug-in system.

I was very, very dogmatic about what would go in and what wouldn't go in. And I look back on that dogmatism now, and I'm grateful for it in some ways, but I also realize that one of the important things about an open-source project is that you have a way for people to be able to make contributions. And in the beginning, I was really, really guarded about stuff. And part of it was that the tools that were available, subversion,

we had our own subversion repository, and the tools just didn't allow you to take contributions like in the way that it happens on GitHub. Now on GitHub, if you trust somebody, you can press a single button and their changes get merged in kind of thing. Now, you should be running the test on that before you do that. But the point is that it's that easy now to pull in changes from other people. So at the time, I can remember when Sean started using Git and GitHub came out, and this was before Radiant was doing that. At the time, we were a whole lot more guarded about, like, who could commit stuff and how. And there's definitely, It's a challenge because you want to be clear about the direction you're going in, but you also don't want to, like, discourage creativity and

contributions because there's going to come a time if your open source project is successful when you just get burnt out if you're doing all of the work, right? So I think one of the things that I think about more is, like, how can I allow someone else to take over this responsibility? And it's hard because, like, well well I'm a perfectionist I'm a perfectionist in terms of the way that I look at code I'm a perfectionist in the way I look at interfaces and all that kind of stuff

and so like if something is not perfect when it goes into the application there's a part of me that like dies it's so important to me that like dies you know um it's just it's so important to me that it like it be right and yet i i've had to kind of learn to to back down from that and recognize you know what this is the the way that like it works when you're on a team you know one person contributes something it may not be like the best but it's like filling a gap and it's progress yeah it's progress it's going in the right direction and um so i think in some ways as far as the way that Radiant went, I was really fortunate that Sean Cripps came along in particular, in that he was able to slowly kind of wrench the code away from my fingers and start submitting stuff. And then at a different point, Sean gave other people

some of their rights to the project. You know, at some point, you kind of realize that, like, you can't do it all yourself. And that if anything's going to happen, you've got to, like, turn over the reins and let people go with it. And people grow into these things, which is really neat to me, watching the way that open source works.

We've definitely seen on Radiant our developers grow in the way that they interact with people and the way that their coding style improves and various things like that. And giving them kind of a home, a place where they can do that is really vital to successful open source, I guess. So it's been a learning experience working with RADIAN. I think I've been really fortunate the way that things have fallen out. My dogmatism could have killed the project in the beginning. I recognize that now. But, I mean, it came really close at a certain point.

And it was just because we decided, you know, we're going to do an extension system that, you know, that didn't happen. Because people had a place where they could work out their frustrations with the way that Radiant was in a different way. So when you're not hacking on the client projects that you do, you'd mentioned that you work with Tralien and a few other client projects that you work on. But when you're not doing that and you're not hacking away at Serve or this fun dream called Acoustic or maybe even managing or working on Radiant.

What other open source projects got you excited that you like to mess around with? I am very excited about Compass right now. That's a big one. I am not as much of a contributor to other open source projects as I probably should be. I did commit some or work on some different parts that were in early versions of Rails. Definitely having fun with RAC, just getting to delve into that a little bit with CERV has been fun. I find it really fascinating that such a simple interface can be extended in so many cool ways. There's

a little application out there and actually it's a RAC handler called Rack Lobster, which is a web application that prints out a lobster on the screen. And I can remember when I discovered that thinking that was the most hilarious thing. Yeah, doing a little bit with jQuery plugins occasionally, writing some of my own. I've done a lot with Prototype, and there's a library by Dan Webb that adds some class selector stuff to Prototype that I enjoy. That's called LowPro. Yeah. That would be a couple. I think one of the fun ones that I'd like to dive

deeper in with you would be what you like about Compass. And you said Compass specifically and not Sass. I'm kind of curious why you just said Compass. Oh, I guess I kind of think of Compass and SAS as being sort of the same thing now. Right. I kind of do too.

I just wondered if there was, you know, you kind of like what was happening in Compass more so than SAS. Yeah, I mean, both of those projects are definitely evolving. I guess the joy that I get out of it on a daily basis, just the stuff that Chris Epstein has put into Compass, all the CSS3 stuff, being able to take advantage of that in a way that, like, works across browsers, I love that stuff. I don't think I would be messing around with CSS3 if it wasn't for Grills and Compass because it's just a pain to write all of those attributes like 80 times. Yeah, it is probably the biggest. I think that there's any CSS developer listening to this podcast right now,

if you haven't touched SAS or Compass, you owe it to your future career to go get started right now. But yeah, especially when you're talking about CSS3. I just saw a tweet today from one of our good friends. Let me see if I can refresh my tweet screen so I don't recall his name. Jeez, he's so well-known, too, and I can't recall why his name isn't coming to my mind, but he works at Intridia, is really well known for writing tons and tons of plugins. He's more of a developer than he is a designer, but he's also a designer. And his name is Mike.

Can't recall his last name. So horrible. Anyways, sorry, Mike. But he had said basically that... Geez, I totally lost the train of thought that I was even talking about. Basically, he was just saying that because of SAS and because of Compass, or because of CSS3, he's never touching Photoshop ever anymore. He's pretty much just having fun in Illustrator and right in the browser. And that's kind of my take too, is like as soon as I picked up CSS3, I pretty much don't even do that.

And I probably am like, QHUD wouldn't have picked up CSS3 sooner as I have or even have as much fun with it if it weren't for just writing one line to, you know, put out border radius versus eight. Yeah, I love that aspect of it. SAS, I could say a lot on SAS too, just the way that it allows me to kind of write my own,

to structure my code well as I'm writing CSS. I haven't so much developed, I wouldn't call it a library of SAS code that I use so much as I tend to copy modules from project to project. So I have a typography module that's got a lot of defaults in it for the way that I like to do the style, you know, my typography. And being able to do that, share the code in that way is huge. And the way that I'm able to create small little modules that do one thing and then use that everywhere throughout my code. Yeah, I love it. It's great. Yeah, I think Compass being able to framework in general,

people might be misguided with what Compass is, and when you say it's a CSS frameworking tool, in the end, the libraries within it aren't really frameworks. Like, for example, Blueprint and 960GS, those aren't really frameworks. Those are more so libraries, as Chris would say. And Compass, theoretically, is the frameworking tool because it allows you to truly create a framework of your working style. Like, I'm sure you have a structure for your SaaS that makes sense within working with

SaaS and Compass, and I do too. And that's really what I love about it. It's like you can kind of get into your grooves find your optimizations find your ways that you streamline the way you do things and you can just like pattern that with compass and sass and just go yeah yeah um i mean i think fancy buttons is a good example of a um of a framework i I guess, within... that's being distributed with Compass. Well, with Compass in mind, just so... For those of you that don't know,

Fancy Buttons contains a lot of CSS code for styling buttons in a bulletproof way. And if you use it on a project, you get access to a couple of mix sounds that would allow you to create buttons with a single line of code. You just tell it the color that you want, pass a couple of options in,

and it does the rest. I almost think you should have made that project called, it should have been called Magic Buttons or something like that. Yeah, I don't know. Because it's like magic. If you know Brandon, Fancy's kind of cool. It's the most excellent Fancy Buttons project.

Yeah. Now, we love Brandon. He's been on the show before. You know that. But Brandon's awesome. I met him a couple years ago at my friend's conference, Les Conf, and he's a good guy. And I certainly look up to him and his code and what he does.

And he's big in the SaaS and Compass world, and he's done a lot. And Fancy Buttons is super, super cool. But that's what I love a lot about Compass and a lot about SaaS. So I echo whenever I'm not doing pretty much anything i do do is is in and around the compass ecosystem like i've got a bootstrap for serve that i do that's got a lot of my fun things in it because i've been using serve quite a bit um so yeah sass compass is always in my projects and hamill as well but uh i don't cry when I can't have Hamill, but I can certainly feel the pain.

Yeah, I think I could live without Hamill, but I probably couldn't live without FAST now. So much is a part of what saves me time on my projects. Well, John, we certainly appreciate you coming on the show and sharing your feelings about open

source and your continued optimism for open source, as well as the work that you've done with Radiant and building that community and the work you're doing on Serve and all the stuff that you bring to the community and the ecosystem. I know that Wynn and I both certainly enjoy what you do, and I think you're an awesome designer, and it was fun having you on the show. So thanks for coming on. Yeah. Well, I really appreciate the invite. It's just great. I love what the changelog does, and it's fun to be on the show. Awesome, thanks. See you next time.