The Baen Free Library

A couple years ago, I was stranded at home with a broken ankle. Since I had just purchased my loft, and was only staying there a couple days a week (the rest of the time at a crashpad near work), I had no cable TV. Shoot... not even a TV. No internet either -- I was "borrowing" connectivity from a neighbor, though it was a crappy connection.

How to pass the time?

I figured reading a book would be good, but I certainly wasn't capable of getting myself to a bookstore. Then I recalled the Baen Free Library. I'd run into it, in some story about how publishing free content can actually help your business. Eric Flint wrote a page about why they are giving away books for free. The man gets it.

So... off I went. Through the crappy connection, I was able to get several books downloaded, and settled in to read them. One of those books was 1632, a story about a West Virginian town picked up, in whole, and thrown back in time and relocated to Germany. It is the first in a long series by Eric Flint. And it is really, really good.

And this is exactly why I say that Jim Baen gets it. After reading all the free books in the series, I went on to purchase another eight books or so. Baen Books made money where they otherwise would not have.

I have recently returned to the B.F.L. in a quest for books for my Kindle 2, which I got back in March. Yes, they offer their books in Kindle format. Lately, I've been reading the books from The Belisarious Series. The first four are available for free in the B.F.L., and the last two are free on Baen's Fifth Imperium website.

I'll end with a note that the B.F.L. is housed on webscription.net, which sells quite large number of books, and all available in Kindle format. There are even some books that Amazon doesn't provide in Kindle format (like the excellent Paladin of Shadows series by John Ringo).

[Update: Eric Flint wrote that web page, not Jim]

My Bacon Number

No, not the tasty pork product.

The actor...

I've just discovered that Wil Wheaton has a Bacon Number of One, after appearing with him in She's Having a Baby.

Back in 2004, I played poker with Wil after his keynote speech at ApacheCon in Vegas.

Thus... my Bacon Number is Two.

Modern Day Racism

I twittered a pointer to a story about "Buy Black", and noted that it is just racism under a different label. Twitter is not a very good outlet for really discussing something, though.

I think the key question here is, "should business ownership diversity match the diversity of the population?"

If you answer "yes", then we need to fix these inequities, too:

• overrepresentation of Mexican ownership of Mexican restaurants
• too many Chinese-owned Chinese restaurants
• way too many asian-owned dry cleaners
• what's with all the Jewish diamond merchants? Get whitey in there!

I could keep going, but I hope you see my point. Why must business ownership match? Aren't you being racist by only buying from a black-owned business?

Now, granted. I can see supporting black ownership if there is something truly keeping them "down". But I would counter that Obama blows apart the notion of blacks being held back by "The Man". Hell... a black guy is The Man.

If you want to fix an inequity, then your time could be used to fight against the glass ceiling endured by women.

(and before anybody comments: yes, I use "black" just like I'm "white"; most Americans were born in the US and have nothing to do with Africa)

The Licensing Conspiracy Idiots

When I worked at Google, one of the things that I got to do was choose the licenses that were allowed on Google Code. A quick consultation with Chris DiBona to ensure that I wasn't totally in left field, and that was it. We launched Google Code with seven licenses, and added an eighth (GPLv3) when that license was released.

I'd been observing the use of licenses on the site, and saw that the uptake on Mozilla was dead last. I mean really last. Less than a few percent. After many months of saying "we should axe that license", I actually dug in and killed it off.

And then the conspiracy nutjobs came out of the woodwork. Saying Google had some Master Plan and how it didn't like certain licenses. That it was trying to kill off licenses to further its own ends. Of course, I'd seen this utter nonsense before, so was ready for it.

The simple fact is that my goal was to reduce the number of licenses that people use for their Open Source projects. When you combine multiple software packages, the combinatorics around licensing just becomes insane. "Can we combine these? What are the overall requirements? What notices are necessary? Which pieces do we need to provide source for?" All of these questions become very difficult for the end user, and for packagers/redistributors.

Our job, as authors, is to help these people. Open Source and Free Software should be easy. We should not be wasting so much time on licensing (our own, or the people who consume our software).

In an ideal world, I believe people should choose the Apache License, v2, or the (GNU) General Public License, v3. Pick one based on your philosophy.

Middle-of-the-road licenses like MPL, EPL, and CDDL are wishy-washy. They can't decide to be permissive, or to maintain Freedom. Choose a philosophy.

And the experience on Google Code showed that people simply do not tend towards these wishy-washy licenses. Instead, they are chosen for your depending on whether you play in the Mozilla, Eclipse, or Sun playgrounds. Those licenses are not universal. So I took a step to help in that direction. Worst case, a few percent of projects would be hosted somewhere else with more choice around licensing (such as SourceForge).

The idiots barking about the Affero license totally missed the point. No conspiracy. They just had no numbers, and were fragmenting the licensing market. Go host your projects elsewhere. You never had and never will have an "entitlement" to host on the service of your choice. That is up to the service provider, and Google Code chose the path of limiting license choice.

Anyway. If you want your software to be adopted and used, then pick ALv2 or GPLv3. That keeps things very easy for your users.

Now go write some code.



(after I left, somebody added MPL back, along with EPL and CDDL; ah well... their choice now!)

Europeans Smoke Too Much

I've become very used to heading into a bar in Europe and wading thru smoke. I keep a machete on hand for just that purpose -- it is that thick.

And here is my obligatory stereotype comment: European is full of smokers. Fine with me. It's the culture. I'm not about to tell anybody to stop. But I am happy to return to the United States where the anti-smoking peeps have dug in and keep the air smoke-free in restaurants and bars and whatnot. Here in EU? I just deal. No complaints.

Today? Oh, dear. I've realized that the people here have elevated smoking to a whole new level. Not quite to Millenium levels, but wow.

I was out walking through the nearby forest / park. Some serious stuff here, with big trails for walking, biking, and even horses. Today, I finally saw some peeps on horses. They're at walking speed on the trail, going the opposite way. And guess what?

They're smoking. On the back of the horse. In the beautiful outdoor forest.

Sigh.

I hope these people will wake up one day and realize the world is a much more beautiful, clean, and clear place, when the haze of their smoke is not filling their lungs and face. I don't mind (lots of fresh air out there), but I feel bad for them ... not realizing what they are missing.

Commit Access: It's a Social Problem

Many proponents of distributed version control systems (DVCSs) say the biggest advantage is that anybody can create a branch and begin working on a project. Whereas, for a centralized system (such as Subversion), the would-be contributor needs to have commit access before they can contribute.

Let's walk through this.

Obviously, this contributor can grab a tarball, make their change, and send a patch file to the project's mailing list. No commit access is required to do that. Why a DVCS, then? Well... the DVCS simplifies the retrieval and application of the patch (by the project's developers, or third-party users of the project). The contributor also gets use a version control system while developing the patch, which I'll just axiomatically state as a Good Thing.

Okay. So if they don't have commit access, then a DVCS is very handy. What would the scenario be if they did have commit access? The contributor could develop their change on "trunk" or on a branch. We've already stated this is a would-be contributor -- not one of the regular developers who already has commit access. It really doesn't make sense for this person to modify trunk directly, so let's just say the work is being done on a branch.

So why would this potential contributor not have commit access? Really? All their work is happening on a branch. It isn't like they're going to mess up the project from over there. They're going to generate some commit emails, sure, but maybe the other developers could then provide pointers, assistance, and feedback earlier than if the contributor had arrived with a patch, as a fait d'accompli. This is source control, people. Anything changed can always be reversed. No permanent harm is possible.

So why do potential contributors not receive commit access to a branch, as soon as they ask for it? For social reasons. It certainly isn't technical. Projects have an us versus them attitude, and they don't get to commit to our repository.

For reference, I'll note that the Apache Software Foundation provides branches to Google Summer of Code students. These students arrive with no credentials, they get a branch, and then work on their code over the summer. When they are done, the work can be merged back to trunk, if it is acceptable. It has worked out very well for all involved.

In the Subversion project, we set up branches for developers to try out their ideas. We say these developers have "limited commit access" rather than "full commit". I'll also note that there are no technical limitations on their commit access. Those developers could commit to trunk if they tried. But social restrictions prevent them from doing so. We've never had a problem with rogue developers, since it is so easy to undo any mistakes or intentional harm, and to remove their access.

In this respect, DVCSs are simply a workaround to social barriers put into place by projects. They do not address the core problem: projects should be inclusive rather than exclusive.

Answer One, Ask One

whurley is trying out a fun series of question/answer posts on his site. He asks somebody a question, they answer, and get to ask him a question. He asked me whether distributed version control systems (DVCS) are bringing about large changes in the Open Source ecosystem. I asked him about Netbooks.

Check out the questions and answers.