We launched Project Kenai very quietly last Friday. It’s a developer hub with SCM and issue tracking and forums and all the other stuff you’d expect. We built it because we needed it, but it’s open for use by the world for free. For a newborn infant, it looks pretty good. Anyone can visit, but to create a project requires an invitation, which I have some of; contact me if you want one. There are lots of interesting things about Kenai; among other things, it’s a Rails app. Herewith the details.

[Update: Nick Sieger responds to heat over “control”.]

Disclosure · I was in on some of the project planning at the beginning, and have been on some of the mailing lists, but really can’t claim any credit. On the other hand, I think I was the first person to suggest, back when this was getting started, that we do it in Rails. Once the shock wore off, there was little pushback.

Nick’s Take · I went and pestered the engineers to blog about the actual technology but they claimed they were busy. So I tracked down Nick Sieger, one of the ringleaders, and got him to spill the beans in an interview format.

Tim: My understanding is that Kenai is competition for GoogleCode and GitHub and so on. Is that right?

Nick: You could look at it that way, and at face value that’s certainly true, however it’s not our goal to directly compete with those services. Kenai is a recognition by Sun that, as the largest open source company in the world, we need to take control of our own destiny. We need a place to nurture and grow our open source communities that we ourselves can control; we need to demonstrate credibility in building on top of more traditional LAMP/SAMP web stacks (not just Java EE); and we need to show viability of Sun technologies and hardware for next-generation web applications.

By launching, I think we’re well on the way toward showing progress toward those goals. Where we go from here is going to be a blend of what the community asks of us and our own ideas for what we think would be cool new features to build on top of a collaboration portal that no one else has done yet.

Tim: What’s your role?

Nick: I’m the lead developer. Some might accuse me of being the architect as well, however I believe that the project’s architecture is a shared responsibility for which I serve as ringleader. We’re learning a lot as we go, myself included of course.

Tim: The sound-bite is, it’s a reasonably conventional Rails app with a stew of OSS components and Sun-flavored technology behind and underneath. Want to give us a tour?

Nick: We’re using Sun T2000 servers along with an X4500 for storage. OpenSolaris Nevada 70b is the OS. (We haven’t been able to upgrade to OpenSolaris with IPS yet because there is no SPARC port of IPS. We’re eagerly awaiting it though.) Apache runs in front, using mod_proxy_balancer to connect to multiple redundant GlassFish V2 instances talking to a single MySQL database. The main site is a Rails application running on JRuby, deployed in GlassFish as a war file built with Warbler. Perl, Python, and other various bits of Apache-based bailing wire help integrate Mercurial, Subversion, Sympa (mailing list software) and Bugzilla into the mix as well. Also, my teammate Fernando Castano just gave a great overview of our system at RailsConf Europe last week. His slides are available if you missed the presentation.

Tim: How much Rails experience on the team, going in?

Nick: I had a couple years of Rails experience, but not on any full-time projects. Rails and Ruby were an entirely new thing for the rest of the team.

Tim: What were the really hard parts?

Nick:Not surprisingly, Rails is not one of them. Beyond the initial learning curve of the “magic” that is Ruby and Rails, most of the difficulties were in making system configurations uniform and deployments repeatable.

We got the feeling of being one of the first to build this kind of application with this combination of Sun and other open source technologies. We hope to help ensure that other people won’t have to feel the pain we went through to build on top of this stack, because now that we’ve got it up and running, we think this could be a great base for building highly scalable web applications.

Tim: If you were doing it again, what parts of the design would you change?

Nick: It’s too early to give a definitive answer. Application-wise, there will continue to be things in the user interface we want to change. Deployment pains have been part of the problem, and having a rock-solid approach for that from day one would have been a big win. Systems configuration and automation still seems to be the secret story that you don’t hear much about.

Tim: What are you guys working on now?

Nick: In the near term, we want to beef up the feature set to make it more usable for daily development by students and open source projects. We want to add a files facility to host project binaries and downloads. We want to add JIRA as an issue tracking option and Git as an SCM option. An incremental refresh of the site navigation and layout is also in progress.

Finally, we want to establish a pattern of responding to community feedback by releasing frequently. You can post feedback in the site forums or visit kenai.uservoice.com to vote for your pet feature or improvement that you’d like added to the site.

What I’m Doing · I transferred mod-atom to Kenai; not much to report yet. Setting up the project and dumping it into Subversion and checking it out again and adding another committer and making a couple of changes; it all worked, and was snappy, big deal.

The world needs there to be a small number of developer hubs in active competition; the state of the art is young and there are lots of low-hanging fruit, so I expect rapid progress from Kenai and its competitors.