DevFi

In our sophomore effort we talk about some of the considerations needed when releasing a project under an open source license. We briefly discuss license choice, hosting your project, and why you might do so at all. We also touch on the expectations that users have once you’ve released your code, when to release, and how to let people know that you did.

In the show, we promise an interview with Ara Howard. When we actually get his answers, we’ll post them here.

If you’re looking for a comparison of licenses, check some of these links:

• Licenses at opensource.org
• Steven Fishman’s overview
• A simple chart by Zack Rusin

We’ll go back to both using one good microphone next time, when we talk about version control options and encouraging participation in your open source project.

---

Downloads:

• Audio – M4A
• Audio – MP3

In our inaugural podcast, we discuss reinventing the wheel vs. buying a wheel vs. customizing an open-source wheel. When is one a better choice over the others? We tackle that and more.

We also have an interview with Dan Berger, long-time Ruby developer, who recently forked the Ruby interpreter, creating the Sapphire programming language. His full answers are below:

---

Is Sapphire good or bad for the Ruby community?

It’s good for the Ruby community the same way that Perl or Python or any other language is good for the Ruby community. Many languages have ideas that language designers can (and do) borrow. If the features I add to Sapphire prove to be useful and popular, there’s at least a chance that those features will be merged back into Ruby.

Do you see Sapphire as a long-term commitment, and if so, will it be a side- or full-time project?

It’s definitely a long term commitment, and one that I’ve put off for a long time precisely because I know how much work will be involved. For now it’s a part time project, because I have a full time job, and that limits how much time I can put into it. I’d love to work on it full time, though.

What specific changes have made [will make] Sapphire more Windows-friendly than Ruby?

Several core classes will be refactored, either to take advantage of native system calls or to fix incorrect behavior. This primarily affects the Kernel, IO, File, File::Stat and Process core classes. For example, IO.readlines will use scattered IO for improved performance on large files. File.basename and File.dirname will be fixed to work properly with UNC and root path names. Several methods in File::Stat that don’t work or aren’t supported will be made to work including, shockingly, the fact that File.size breaks on file sizes over 2gb on Windows. The Process.kill method will be improved to use a less brutal termination method. The list goes on.

The standard library will see improvements by replacing Unix-only libraries with cross platform solutions or by refactoring existing libraries to become cross platform. For example, the etc library has been replaced by sys-admin, the dbm/gdbm/sdbm group of libraries will be replaced with kirbybase, and open3 will be made cross platform.

What sort of projects/developers would benefit switching to Sapphire from Ruby?

The sort that would like to have features integrated into the core language that Matz hasn’t expressed any interest in. I think Ruby is already falling behind languages like Python or Scala. Those languages, and others, have useful features that could be integrated into Ruby.

I also suspect that Sapphire will appeal to developers who are unhappy with the way Ruby is being managed and some of the features that are being shoveled into the 1.8.x branch.

Are any of your concerns about Ruby being addressed by the 1.9 effort? Or Rubinius? Or JRuby?

When it comes to MRI, other than Unicode support, not really. The primary issues are management and evolution.

There is still no real test suite in MRI. The Rubinius/JRuby spec, while a vast improvement, is still an afterthought among the core Ruby team. Plus, the spec itself is a moving target, especially with some of the major changes that 1.8.7 just incorporated. Mostly it’s still a case of Matz using the end users as beta testers. There’s no attention to compiler warnings, which can be significant, and virtually no effort goes into refactoring. That trend isn’t going to magically stop with 1.9/2.0. The upshot is that the end users are left to find the bugs, usually the hard way.

There’s also the issue of dealing with bug reports and patches in a timely way. They’re often ignored for months or even years at a time. The same thing has happened with patches. Eric Mahurin’s array.c patch was the most notable example, which some people may remember from the Zed Shaw rant.

When it comes to evolution Matz is moving Ruby in the wrong direction in my opinion. I see a lot of obsession over proc/block/lambda notation and semantics and a bunch of marginal methods being shoveled into the core language. Instead, I’d love to see some of the evolutionary changes that languages like Scala, Python 3000 and Fortress have implemented, along with some other fundamental changes, but Matz doesn’t seem interested. We’ve seen two iterations of the RCRchive fail because Matz ultimately demanded too much of the proposers and eventually lost interest. When he lost interest, so did the community.

JRuby and Rubinius (and any other implementatinos out there) necessarily cannot address my issues either, since they are more or less bound by whatever Matz does with Ruby. That’s a terrible shame really, because I think both the JRuby and Rubinius core members could incorporate some fantastic ideas into the language, such as type inferencing (as Charles O. Nutter did with Duby) or Behaviors from the old Sydney project. But, unless Matz gives the thumbs up, they’ll have to be side projects. That puts them in a serious dilemma.

If Ruby core were to ask to merge your changes into MRI, would you be willing and would you give up Sapphire?

No. It would never happen anyway because my changes require as much ripping out as they do adding in. Furthermore, we have seriously differing opinions about where the language should go and how it should be managed as I discussed previously.

---

We’d like to thank Dan for taking the time to answer our questions, and for open source in general for making project forking a possibility.

Join us next week when we talk about releasing an open source project and all it entails.

---

Downloads:

• Audio – M4A
• Audio – MP3

No matter how you say Hello World:

printf("Hello, World!\n");
std::cout << "Hello World!" << std::endl;
print "Hello World!\n" 
puts "Hello World!" 
write("Hello, world!\n")
echo "Hello World!" 
putStrLn "Hello World!" 
io:format("Hello World! ~n").
alert("Hello World!");
(message "Hello World!")

We’ll have something interesting for you on the DevFi podcast.

Chris and I are working on the first episode, with a planned release date of May 5th.

Our first topic is going to be on using existing software vs. writing your own. We’re also going to touch on forking open source projects, and close with an interview with Dan Berger, a long time Ruby contributor who recently forked the language.