• Read more about What's Wrong With Patents? It's Obvious.

Patents are in the news in the tech circle more and more these days. As trolls lurk under bridges and the portfolio cold war gets hotter and hotter, everyone is talking about the fact that something is wrong. What exactly that something is, however, is up for debate. Should the patent system be abolished? What about just software patents? Is the term too long? I don't know, maybe. But one of the primary issues, from my view as a web startup developer, is that what's obvious isn't really so obvious anymore.

Patents were established as part of a way to codify the Constitution's Copyright Clause attempting to promote science and the "useful arts." They grant a limited term of exclusivity for inventors in exchange for publishing the means to reproduce the invention. In theory, this is a win-win: the inventor gets to make money off of their invention and the public gets to know how it's made. Other individuals or companies can even license the right to reproduce the invention before the patent has expired so it may reach even more people than it would otherwise.

I'm not going to get into arguments about whether or not the patent system as a whole encourages innovation in modern times. However, one of the requirements of getting a patent is that it not be obvious to "a person having ordinary skill in the art." I believe that this requirement is no longer adequately strict for patent issuance due to three fundamental differences between the establishment of the system and today's field of "inventors": population, communication, and specialization.

Matters of Population

There are more than 300 million people in America, more than 100 times as many as when the country was founded. That means that for any given "art" there's a great number more people in any particular field than there used to be. So how does this affect obviousness?

If eight people out of ten couldn't figure out how to do something, maybe it's reasonable to let the one out of two that figured it out first get a patent on it. That incentivizes the two that can figure it out to figure it out because there's a real chance that they'll break ground first and make some money off of it.

So let's increase the field's population a bit. Now let's apply the same ratio to an invention but there's 1,000 people in the field. That means that 800 out of 1000 would find it non-obvious, but 200 out of 1000 would. A person of "ordinary skill in the art" still would allow the patent to be issued, but now we're talking about 200 separate people who would find it obvious. This isn't inherently a problem if all inventions existed in a vacuum, but most often patented ideas (especially in software) represent only part of a larger vision or system. That means that because one out of 200 people happened to register for a patent first, their larger system is in the clear while 199 others that could be solving totally different problems but using the same invention as a part of their larger vision are now in jeopardy of owing licensing fees or being barred from pursuing matters entirely.

In modern America any given field will have tens of thousands of people all working, collaborating, and inventing. To posit that the standard by which exclusive, multi-year rights to something should be given to something that's non-obvious to the average person doesn't ring true. It should be something unique and groundbreaking enough to be non-obvious to the vast majority of people in the field. To merit exclusivity, it should be something so beneficial that the inventor would fight tooth and nail to keep it secret were the advantages of patents unavailable. Instead, hundreds of patents are issued for mundane, completely foreseeable advancements in the art. Just because something is non-obvious to most people doesn't make it a breakthrough invention.

Proliferances of Communication

Can you even imagine how things must have worked back in the late 18th century? What would it have been like to be a scientist, a researcher, an inventor? Compared to the always-on global communications networks that researchers, engineers and inventors have today it's an entirely different world. Lots has been written about how the world is "shrinking" as both travel and communication between disparate places becomes easier and easier, and the same goes for the inventive communities who are churning out patents.

This readily available communication has the effect of making all participants in a field effectively smarter than they would be otherwise: if I don't know how to do something, I can just Google it and now I do. This has implications again for the consideration of the "obviousness" of patents. Are many of the things patented today non-obvious to a person of average skill in the art with access to the internet? I'm not so sure.

Especially Specialized

Over the course of our society's development we have gone from an agrarian society to an industrial one and now to an informational one. The level of specialization found in the modern creative force makes it pretty difficult to tell exactly who should be considered a person with "average skill in the art." As a disclaimer, I'm not actually sure how the courts currently make such decisions, but it surely is a more complicated question than it used to be. Where do we draw lines of separation for the "arts"?

Is the peer group for a new mobile device patent other mobile device engineers? Is it other device engineers? All electrical engineers? I'm not honestly sure how you would draw that distinction and where you draw the line will drastically effect the determination of average skill in the art.

Abandoning IP

So what is to be done about the patent problem? Well, my guess is that the growing tsunami of patent litigation is going to lead to some kind of change in the law. The current situation is pretty untenable, and I think it's only going to become more so. Something big will break loose in the next few years and I think the landscape is going to change dramatically.

There are multiple fronts on which the current patent system seems to be at odds with proper innovation, and one of the biggest problems in my eyes is that it is only larger, heavily established and heavily funded companies that are even trying to get patents. You don't see garage startups wasting their time trying to eke out software patents: they're too busy building. It's not until a company is big enough that it can afford to split its focus and hire patent attorneys and do what is necessary to start "protecting" its IP. That bothers me, because it's propping up a system of innovation where only the big established players have a chance to exclusivity on their "inventions," and in my mind those are the people who need protection the least.

Technology moves orders of magnitude faster than it did in "the old days" and I'm not even sure where patents fit anymore. 18 years is several lifetimes by current standards of advancement, and to lock up a technology for that long is equivalent to locking it up for the entire span of its usefulness.

Coming from an open source software advocacy background, patents seem like a greedy, antiquated version of what thousands do every day for free: sharing their technology with the world for the benefit of everyone (the creator included). In a world where everything can change in a matter of months, I think it's time to stop worrying about protecting IP and time to focus solely on creating things of lasting value. Don't keep your competitors from using your innovations, just make newer and better innovations that outpace them.

• Read more about Ruby Thankful

A lot has been made in the talkosphere recently about the brewing "multi-Ruby version manager" war, namely RVM vs newcomer rbenv. I'm not here to discuss the relative merits of either software solution, mostly because I take things pretty simple and straightforward in command-line world and I've never run into problems with RVM. What I do think this little fracas displays, though, is a common thread in the Ruby community of having big, blown-up controversies when new things come along. In some ways, I think that such drama is one of the unique features of the Ruby community that make it so vibrant. It's also a feature of the community that can lead to community casualties.

RVM vs. rbenv, Test::Unit vs. RSpec, HAML vs. ERB, Rails vs. Merb, Coffeescript vs. Javascript, Mongrel vs. Thin vs. Passenger vs. Unicorn, Cucumber vs. Steak, and the list goes on. It seems like the Ruby community has a habit of drawing battle lines every month or so. Why do these "fights" come up so frequently in our community? More importantly, what do they mean for the overall health of the community?

Today we're launching a little site called RubyThankful. It's barebones at the moment and open source, but what it represents is hopefully a way to find some positivity in the Ruby community.

Background: Passionate Programmers

I would argue that controversy breaks out on a regular basis in the Ruby community because, more than any other community in which I've participated, Rubyists are singularly driven to use not just good-enough tools but ideal tools. Ruby is a community of chaotic reinvention, a community that will jump off a cliff just to try out a new brand of parachute. It's that passion that draws me to the community, that makes me feel like the things that I do matter. It's also that passion that can cut to the bone.

People are inevitably going to form opinions about what they think is the best in a field of competing libraries/tools/products. This competition in the commercial marketplace is what drives high quality and low prices, and in the open source world it's what drives reinvention and continual progress. If a library isn't pushing its users forward, those users can and will seek out a different library that better meets their needs. This is natural and generally beneficial.

What isn't maybe so beneficial is the "what have you done for me lately" attitude that can come with our pursuit of the perfect development process. It's altogether too easy to write about reasons why "Y is better than X" while forgetting about the fact that before that, X was so much better than nothing at all.

Casualties of Harsh Reality

As I began to write this post I saw Steve Klabnik's We Forget That Open Source is Made of People. It'll be hard not to re-iterate many of his well-reasoned thoughts here, so I want to give him credit for making a point that needs to be made. I was also amazed to come against this controversy just one day after I wrote a post that included the sentence "Harsh words can sometimes be enough to completely dissolve the creator's interest in continuing the project." We've lost amazing members of this community because rather than respecting their contributions we tear them down when something marginally better comes along. This is the dark side of passion.

I like some tools better than others. I've even written blog posts debating the merits of one approach over another and declaring one superior for my purposes. I've been guilty of jumping onto new technologies and giving nary a thought to the old way of doing things. I don't think it's possible to stop this community from being obsessed with the new and different, and I don't think that's what needs to happen. What needs to happen is that our community needs to get better at raising our voice in something other than protest. We need to temper our enthusiasm for the new enough to at least be civil to the hard-working people who created the tools we used until oh-so-recently.

I'm as guilty as anyone of this. Short of trying to say "thanks" in person to the creators and maintainers of the tools I use every day when I see them at conferences, I don't take much time to thank people for the amazing things they've done to make this community what it is. This all sounds sappy and somewhat inefficient, but I think it's a vital piece of maintaining a healthy community.

Ruby Thankful

I almost wrote this just as a blog post to say "hey, let's be more positive and thankful." I was just about to post it when I realized I could do at least a little bit more than that. So I built an almost-nothing-to-it site that can serve as a public forum for the Ruby community's gratitude for those who work hard to make it what it is. Just tweet something with the #rubythankful hashtag and it'll get picked up. Maybe it's someone you're thanking for a library, or their blog post or tutorial that helped you out, maybe it's something else. If you're thankful for the Ruby community and the members of it, let's put some voice out there!

This community has given me a lot in the last four years, and I've done my best to give back. But I haven't always been thankful enough to the individuals who create the things that I use every day. Hopefully RubyThankful is a small way to encourage that to change.

• Read more about What if Rails Isn't For Beginners Anymore?

There's been a lot of controversy surrounding the changes to Rails 3.1. It started with an epic GitHub commit thread and the discussion exploded again in the past few days after What the Hell is Hapenning to Rails and Yehuda's response thereto. I'm going to address the issue from a perspective that honestly hadn't even occurred to me until I just said it while in a conversation with some Kansas City Ruby folks after the last meetup: "What if Rails isn't for beginners anymore?"

Rails gained its popularity on the strength of its simplicity. The 15-minute blog was a shockingly powerful demonstration of what the framework could do, and from there it has gained thousands upon thousands of dedicated developers. But that's just the thing: now it has thousands of dedicated developers. And these developers are building some of the most powerful and advanced web apps anywhere on the internet. It's only natural that as the needs of the community grow so too does the framework. What we may be seeing is a point where Rails is becoming the tool for Ruby web experts instead of Ruby web novices. But if that's true, is it necessarily a bad thing?

I built RailsWizard as part of the Rails Rumble last year and I thought it would be a tool that would serve two purposes: help me quickly spin up new apps I'm working on and also serve as a step-by-step guide for novice developers who need to get started building a Rails app. However, two rewrites later RailsWizard is a tool that is incredibly fast for my purposes but almost incomprehensible to anyone who doesn't know what they're doing. The tool evolved to focus on power for experts rather than friendliness for novices. Ultimately that's the decision that has to be made for any tool or website: how much tradeoff are you going to give between making something easy to pick up and efficient for experts?

Since my livelihood depends on being able to rapidly build advanced web applications using Rails, you won't see me beating the drum to take away power from Rails for the sake of novice ease-of-use. In fact, I'm beginning to wonder if Rails is the wrong place to get people started with Ruby web development anyway. There's always been the problem of people who are Rails but not Ruby developers because ActiveSupport and the facilities Rails give you can make it hard to know what's stdlib and what isn't. If people learned Sinatra first, or if the community rallied around a "slightly more than Sinatra" framework like Padrino for newcomers and built up the requisite tutorials and documentations for 15-minute blogs and other things, then the novices who cut their teeth on those tools can come to Rails when they actually understand the power that Rails gives them as developers. They will understand Rails better because they have begun to stretch the limits of the lightweight frameworks and they need more. Maybe a system like that would make for better Ruby and Rails developers.

I'm not saying that any of this is necessarily true, but I think it's another facet of the debate that hasn't been explored yet. Personally I love the changes that have been coming to Rails. The asset pipeline may be the most important addition to Rails since even before 3.0: it is a game-changing piece of technology that has been a long time coming. I think the Rails core team has done an incredible job of pushing the envelope and refusing to remain complacent. And I think that's important, probably more important even than beginner friendliness. Because if Rails gets complacent, if the core team stops pushing out into the weird and uncomfortable, then five years from now nobody will be using it because something better will have come along. And I like Rails.

• Read more about I Heart SASS, But HAML, I'm Just Not That In To You

Emacs vs Vim. iPhone vs Android. Of all of the nerd arguments, none hits closer to home for Ruby developers than HAML vs ERB. Proponents of HAML look at writing HTML as a dirty practice to be avoided at all costs and look down upon "mere" ERB authors. Meanwhile there's SASS, a language syntactically close kin to HAML and, until last week, one that even rode along inside the HAML gem. HAML abstracts HTML, SASS abstracts CSS. I'm not here to stop you from using HAML if you like it. Go for it. However, I'm tired of having an aesthetic choice that some developers make bandied about as if it were "the only way" to do things.

The Difference Between HAML and SASS

HAML is an abstraction of HTML that allows for terse description of HTML elements in a meaningful-whitespace format. Rather than writing:

<div id="profile">   <div class="left column">     <div id="date"><%= print_date %></div>     <div id="address"><%= current_user.address %></div>   </div>   <div class="right column">     <div id="email"><%= current_user.email %></div>     <div id="bio"><%= current_user.bio %></div>   </div> </div> 

You can instead write:

#profile   .left.column     #date= print_date     #address= current_user.address   .right.column     #email= current_user.email     #bio= current_user.bio 

SASS, similarly, is an abstraction of CSS that allows for terse description by allowing for nesting and other conveniences. SASS also includes an SCSS format that looks nearly identical to CSS. For SASS, you go from this:

table.hl {   margin: 2em 0; } table.hl td.ln {   text-align: right; }  li {   font-family: serif;   font-weight: bold;   font-size: 1.2em; } 

To this:

table.hl   margin: 2em 0   td.ln     text-align: right  li   font:     family: serif     weight: bold     size: 1.2em 

OK, so that's HAML and SASS. They both accomplish roughly the same thing, right? Not so much. Here are some of the differences between HAML and SASS:

SASS looks a LOT like CSS. CSS is a series of rule declarations that already follows a relatively terse format. SASS simply adds on the notion of meaningful whitespace and nesting of rules to prevent repetition.

HAML is an abstraction, SASS is an improvement. While HAML and CoffeeScript could be (in my opinion) successfully compared (each provides a syntax that some find more pleasant for writing a certain type of textual content), SASS does something that neither HAML nor CoffeeScript can: it provides functionality that is impossible to achieve in the target compiled language. There's no such thing as a variable, mixin, or function in CSS. SASS provides a thin layer on top of CSS that adds immense power that wasn't there before. Personally, I like CoffeeScript, but I also don't mind writing plain Javascript. I doubt I'll ever again work on a web project where I don't use SASS, because it is simply too useful to ever be without.

Learnability. If I sat down with a designer who was familiar with CSS, I could teach them SASS in less than an hour. Despite trying a couple times at various points, I still have to constantly defer to the reference when I'm writing HAML. I'm not saying that HAML doesn't help some people write HTML templates more efficiently, I'm saying that writing your project in HAML simply guarantees a relatively long and obnoxious learning process for every person who needs to work in the views. Maybe you have a small, fixed team that makes that a possibility, but in many (if not most) real-world scenarios wasting time to teach a templating language that is simply a convenient abstraction is not going to be worth it.

Breadth and Scope. HAML works essentially as a subset of the things you can do in ERB. There are some things that HAML simply won't do (some of these encourage good programming practices, but the statement is true nonetheless). SASS is a superset of CSS; you can do everything you can do in CSS and significantly more. This difference means that SASS will never tie your hands for styling a site but HAML may tie your hands to a specific means of execution in some scenarios. Again, not to say this is always a bad thing, but it's a true thing.

Freedom of Choice

I don't really care if you want to use HAML. I actually can understand how, for developers who don't like writing HTML and CSS (I work on both sides of the development/design fence) it may feel more productive to be able to write things that way. So go for it, use HAML. Just don't tell me that my choice is inferior. We're talking aesthetics here, there is no right and wrong.

There are other ways to accomplish the same terseness that HAML provides while generating pure HTML templates, things like Zen Coding or even just judicious use of some more advanced features of your editor of choice.

TL;DR. SASS and HAML solve two completely different problems. Liking SASS doesn't imply wrongness in disliking HAML. Using HAML is fine if that's your bag, but don't act like it's the only way. It's just an aesthetic choice.

• Read more about You Should Be An Open Source Developer

This post is part of a series called Open Source Citizenry in which I discuss ways to eliminate the barriers that developers and companies face to participating in the open source community.

Last week at Red Dirt Ruby Conf, a tweet came through my stream that seemed to fit quite well with what I was already thinking about for my Open Source Citizenry post this week:

.bbpBox61459124273168384 {background:url(http://a2.twimg.com/a/1303316982/images/themes/theme3/bg.gif) #EDECE9;padding:20px;} p.bbpTweet{background:#fff;padding:10px 12px 10px 12px;margin:0;min-height:48px;color:#000;font-size:18px !important;line-height:22px;-moz-border-radius:5px;-webkit-border-radius:5px} p.bbpTweet span.metadata{display:block;width:100%;clear:both;margin-top:8px;padding-top:12px;height:40px;border-top:1px solid #fff;border-top:1px solid #e6e6e6} p.bbpTweet span.metadata span.author{line-height:19px} p.bbpTweet span.metadata span.author img{float:left;margin:0 7px 0 0px;width:38px;height:38px} p.bbpTweet a:hover{text-decoration:underline}p.bbpTweet span.timestamp{font-size:12px;display:block}

There are still too many developers who work with Open Source and not enough Open Source developers.less than a minute ago via Echofon Favorite Retweet Reply Mike Perham
mperham

In last week's post I tried to give some insight as to why open source is important for companies. This week, I'll be looking at the other end of the spectrum: why should you, as a developer, actively contribute to open source? For some, the answer to this question feels natural; however, for many developers the idea of contributing to open source can be daunting, confusing, and somewhat frightening.

It Will Help You Land Your Next Job

Are you unsatisfied with your current job? If you are, it's a great reason to start contributing to open source. If you're stuck using a language or framework that you don't enjoy, or a development practice that you don't believe in, it's practically imperative that you begin contributing to open source. Why, you ask?

Because the person that is in charge of hiring at the kind of company you really want to work at is going to be looking at an applicant's open source contributions as a way to gauge talent. The more (good) open source you release, the closer you will be to getting your dream job before you've even had an interview.

Open source contributions are a fantastic way to evaluate incoming employees. The very first thing I do when I'm evaluating a potential hire at Intridea is look them up on GitHub. That's not to say that we don't hire people who haven't done much in the way of open source contribution (there's more to the hiring process than a single factor). However, I can say that I am going to be much more adamant in my arguments to hire a person if I can see the way their mind works from the open source projects they've released.

You Will Write Better Code

Open source is open to the entire world. Everyone can see what you're writing. If you think this doesn't have an effect on your willingness to take hacky shortcuts, you're very wrong. Not only does the mere fact that it's open source make you write your best code, but open source also helps you to think about your problem domain from a wider perspective.

As I released more and more open source projects, I began to have a kind of Spidey Sense for when something would make a good abstraction. When I'm architecting a project I'm already thinking about how certain pieces could be built in a modular way to maximize reusability. Even if these pieces don't end up getting released as open source they are still useful extractions that get used in other projects down the road. The concept of building code for a community instead of just for an application makes the work more enjoyable.

Reputation is Real

For a software developer there are essentially two paths to extremely enviable positions of respect in the community: either you can be the tech genius behind a multi-billion dollar startup or you can release open source projects that thousands (not millions) of developers find useful. Guess which one is easier to accomplish?

Reputation isn't just about vanity, either. Sure, it can feel good to have someone say "Oh cool, I've used X!" when they meet you, but building a reputation brings real benefits for you:

1. If you love your company, your company is automatically more respected because you're a part of it if you have a good reputation.
2. You'll get the chance to meet, talk to, and learn from the people that you respect. Not that these people are otherwise inaccessible, but having your own "known" libraries gives you some common ground to strike up conversations, get input, and become a better developer.
3. It will get you hired at awesome places. See above.
4. You will get help when you want it. If you have a good reputation and embark on a new project you'll be able to round up volunteers more quickly if you're a known entity.

It can occasionally feel shallow or awkward (at least to me) to be thinking about and concentrating on my reputation in the community. However, look at it another way: open source reputation is built on real, honest-to-goodness work that is making people's lives easier. And if you start releasing bad code, guess how long that reputation will stick around? Reputation is simply a measure of the respect that others have for you based on the merits of your code. And that's not a bad thing.

That Warm Fuzzy Feeling

It just plain feels good to contribute to open source. The rush you get the first time (as an example) your patch is accepted into a major open source project is exciting. Seeing people using and talking about a library that you wrote is awesome. Hearing that some company that you really admire is using one of your libraries internally is amazing.

Open source feels good because it is good. You are offering value to a community of people free of charge, and in return you get to feel good about yourself and enjoy what you're doing. Don't be afraid to pat yourself on the back (maybe not too hard) for getting code out there. It's more than most people do, and even if only ten developers ever find it useful, that's ten people that saved hours or days of work because of something you did. And that's a warm fuzzy feeling.

Standing on the Shoulders of 1,000,000 Dwarves

Open source is amazing because it doesn't rely on the herculean efforts of a single person or even a few people. Open source is about thousands of people contributing tiny useful things that thousands of other people can build upon. It's not about building the biggest boat, it's about making the entire ocean rise. Each and every person who contributes to open source is making a difference to the ecosystem as a whole, and the more people that get involved the better the whole system works together. There can never be too many open source developers.

Barriers to Contribution

I think it's relatively clear to most developers why open source contribution is a good thing. Additionally, I think there is something intrinsic to the developer's mindset that drives us to crave the scrutiny and the ups and downs of publicly available code. So why doesn't everyone write lots of open source? Here are a few reasons with my responses:

1. I'm not good enough to release open source. Poppycock! My first open source release was literally forking another project and hacking at it until it did something I wanted it to do that it didn't do before. I had no idea what I was doing. I still don't, most of the time, and I've released dozens of open source projects.
2. People will think I suck because my code sucks. Nope, people will ignore your project if your code sucks. That's the worst case scenario. And, to be honest, if you're solving a problem that other people haven't solved, they'll probably use your code even if it sucks. And then they'll patch it so it doesn't suck anymore. Wins all around.
3. How do I even do it? It seems complicated. It's not, especially in the GitHub era. If you want to know how to do something, find a project that does something similar and steal their execution. Just steal and steal from everyone until you understand it well enough to forge your own path.
4. I don't have enough time! Find a way to make time! Identify a piece of your existing app code that other people would find useful and extract it out. This cuts your open source time down to abstraction instead of creation. Work on open source for half an hour a day. Convince your company to sponsor some open source time for employees. Contribute small patches to the libraries that you use on a regular basis. Where there's a will, there's a way.

I could go into detail and examples on each of these points (please feel free to ask me sometime), but the point is that whatever you think is holding you back from contributing to open source, the reality is much less frightening. Your first project will be the hardest to get out the door, but it gets exponentially easier each time after that.

In coming articles in the series, I'll talk specifically about how to be a good open source user, how to be a good contributor, and how to be a good project owner. But if you only needed a tiny push to start getting involved, hopefully I was able to supply it. Please feel free to discuss anything related to open source contribution in the comments, I'd be happy to lend what knowledge I have to the service of getting everyone more involved!

Open Source Citizenry Series

1. Why Open Source Company Culture is Important
2. Why You Should Be An Open Source Developer

• Read more about Why Open Source Company Culture is Important

This post is part of a series called Open Source Citizenry discussing ways to eliminate barriers developers and companies face to participating in the open source community.

Earlier this month I had the opportunity to speak at KCRuby about a topic of my choosing. Rather than use the opportunity to put together a trial run of my upcoming Red Dirt Ruby talk, I decided at the last minute to talk about something that's been on my mind for a long time. While open source participation is higher than it's likely ever been, I still see so many people too hesitant, confused, or intimidated to enter the open source community and start releasing. So I wanted to give a cheerleader talk about how everyone can and should be contributing to open source. You can see the showoff slides here, but I think the issue is important enough to merit a larger discourse. This is the first post in a series in which I will be writing about how and why every developer should participate in the open source community. First up, I aim to supply developers everywhere with some ammunition to bring open source culture to their company.

Why Open Source Company Culture is Important

Companies have many ways to benefit from an open source culture. While many arguments can be made about the philosophical implications of choosing to contribute to the open source community, at the end of the day philosophy isn't going to persuade any CEO to adopt open source. The real reason that open source culture is important to a business is because it's a business decision that can bring many real-world advantages over the proprietary-focused alternatives.

Defining Open Source Culture

There are many degrees of "openness" in a company's culture, just as there is a whole spectrum of licensing that is considered "open source" but can have vastly different ramifications for downstream users. Personally, I believe that many companies would benefit from embracing open source as a core aspect of their corporate identity. To me, fully embracing open source means changing the default. Rather than building things and thinking "Should we open source it?" the assumption should be that yes, we will open source it unless there are compelling reasons to avoid doing so.

This is a big leap for a company to take, and I don't think many are there. We recently acquired RefactorMyCode, and rather than simply taking it over and continuing with it as a product we decided to additionally open source it. There aren't a ton of reasons why open sourcing would necessarily be a huge win for Intridea, but there are even fewer reasons why it wouldn't be a good idea. It's a community-oriented project, it doesn't contain any kind of magic voodoo patentable algorithm, and we can give the public the chance to refactor RefactorMyCode.

It Leads to Better Code

You may run a tight ship when it comes to code quality and you may even have excellent processes in place to ensure that the code that you deliver is well-tested and sanity-checked before it ever reaches production. However, there is simply no review process that can compare to the power of opening up source code to the world at large and letting them take a look. The code quality bump is due to two primary reasons:

1. Developers building things for open source know that anyone in the world can look at the code they're writing. It will make them less likely to take easy shortcuts at the expense of good code.
2. Other people will start using your code way off the golden path you imagined when you designed it. This will cause your architecture to evolve to be more flexible, useful, and hardened.

I know that in many cases I've had to rewrite large sections of a project because the community use cases have revealed a superior architecture that will encompass a broad range of functionality. I then benefit from this architecture when I need a similar solution in the next project I'm working on for my company.

You Get Work For Free

This is probably the most commonly cited advantage of open source: once you build a community, the community gives you free bug fixes and feature updates without you having to code a single line! This is a real advantage, especially when there is a wide-open field for community addition (such as adding new strategies to my OmniAuth library).

Of course, you need to have a workable community involvement process before you can really reap the benefits of contribution. Thanks largely to GitHub, this process has never been easier, but there are still some things to keep in mind that I'll cover in a later post.

Your Developers Will Be Happier

There's a real sense of accomplishment that comes from releasing and contributing to open source. It makes your developers feel like they're giving back, becoming a real member of the development community, and investing themselves more in the craft of software development. The same can be said of encouraging developers to attend local meetups relevant to the field and conferences.

Why do you care about happier developers? Well, every company should care about happy employees, but software development is a black magic mix of science, artistry, and craftsmanship. While some work can be done by "forcing it", a good deal of that work requires inspiration and passion, something you won't be getting out of developers that feel stifled and isolated from the development community at large.

You Will Attract Better Talent

If your company becomes known as one that embraces open source and community involvement, you will begin to attract better talent when it comes time to hire. Sure, having a killer product, good benefits, competitive pay, and many more things affect this strongly as well. But the chance to be involved in open source without having to do so by moonlighting is a chance that is very attractive to the kinds of developers you want to have working at your company.

Open source is synonymous with credibility for many developers. The more well known your company is for having great open source, the higher you rank amongst the development community. It really is that simple.

You Will Gain General Technical Credibility

This may be more applicable to service-oriented companies that do consulting, but in some cases your portfolio of open source projects can be the validation your company needs to win a bid for a client. Intridea has won clients before when they check with their technical expert and he or she confirms "hey, I've heard of that company, they released X".

All of these reasons come about because contributing to and participating in the open source community changes the perception of your company for developers, customers, and other businesses alike. While a company that rabidly protects every scrap of its software might be seen as greedy or, well, basically "jerks", companies that embrace open source foster a general sense of well-being about them that is difficult to define but something that I've definitely experienced personally.

The Flip Side: Addressing Arguments for Proprietary Software

So if, as a developer, you've just made your pitch to the higher-ups to embrace open source, you might receive any of these as (valid, by the way) concerns about being more "open" as a company.

1. But we're a software company, aren't we giving away our most valuable assets? Nope. Well, maybe if you have a completely novel complex algorithm that solves a problem in a game-changing way, but the truth is that most software isn't some "secret sauce" that can't be duplicated by competitors. On the contrary, even with high-level tools and environments at the end of the day a good deal of software development is re-inventing the wheel. The more everyone is involved in open source, the fewer wheels have to be re-invented.
2. We're on a deadline, we don't have time for open source. This can be one of the biggest challenges to overcome. I'm not going to lie, supporting open source projects does take time and effort. However, think of it as a tradeoff: by putting in some time and some effort to maintain an open source project, you are gaining all of the free hours of community contribution.
3. What if people look at the code and think it's awful? Well, then you're learning a valuable lesson about the code quality you're producing and you'll probably be able to identify ways to improve it. Open source projects without tests, with brittle "golden-path" architectures, and even well-intentioned projects that are simply tackling a tough domain are probably going to get some flak. But being wrong isn't nearly as damaging to your company as being ignorant of the practices that you should be using every day.

This post (and this blog series) is more about starting a discussion than providing definitive answers. I'm not saying I know exactly what your company's needs are, but I do believe that embracing open source will do more good than harm. If you have any questions, comments, or rotten produce to throw, feel free to start some discussion below. Stay tuned for the next post in the series where I'll be talking about the benefits to individuals in contributing to open source. And if you're interested in checking out some of the open source work that Intridea has done, hit our Github page.

1. Why Open Source Company Culture is Important
2. Why You Should Be An Open Source Developer

• Read more about Always Be Releasing

It's hard to be "on" all the time as a developer. Despite its engineering aspects, I find software development to be a fundamentally creative act, and creativity requires inspiration. Looking back on the times when I've felt in a slump, when I just couldn't get the energy to make the next big push I needed for whatever project I was working on, I came to a simple realization: I burn out when I'm not releasing.

For me, if I'm not releasing something new at a pace of about once a week, my creative fire is slowly fizzling out. It doesn't really matter what it is; it could be a new open source library, a great (and complete) feature for a product I'm working on, or even just an in-depth blog post. What I need from releasing is the release that it gives me: it gives me license to take a breath, feel satisfied, and let my brain tackle new problems.

If you're feeling burnt out, take a step back and think about something you can release this week. Then do it. If you're really burned out, make it something small, maybe even just a Tweeted gist of some interesting code. Release it, feel that satisfaction, and you might just find that you suddenly have the inspiration and energy you needed to get over your harder, more complicated challenges.

When you really think about it, agile development isn't simply a method for building better software with a tighter feedback loop. Fast iterations and constant releases also serve as an energizing force for a development team, a way to feel that at least something is finished. Perhaps this insight is nothing more than common knowledge, but I know that it's going to change the way I think about my schedule. It's not "what am I working on this week" but "what am I going to release this week". Maybe it'll help you, too.

• Read more about Is Copyleft Really Right for Open Source?

There's an issue that's been bothering me for quite a while. There's a problem in the software development world, a practice that breaks down the free and open exchange of information. This practice is widespread throughout the software development world and can lead to a lock-in mindset that is damaging for the advancement of the community as a whole. I'm talking, of course, about copyleft licenses such as the GPL.

The concept of copyleft seems to be wonderful in theory: it subverts the (arguably broken and archaic) copyright system of protecting intellectual property into a system that requires that information (specifically source code) be freely available, modifiable, and transferrable infinitely. In an ideal world, this leads to companies openly exchanging and contributing to each other's source code, making improvements that the community as a whole can share and defeats the lock-in of proprietary system code. The GNU General Public License (GPL) is the most well-known example of a so-called "copyleft" license and it requires, among other things, that any project which utilizes GPL code that is released must, itself, be released under the GPL.

The First Problem: Rockets vs. Rubber Bands

The GPL truly is a powerful and useful tool in the correct circumstances. The archetypical example of the GPL, namely Linux, is (I believe) greatly helped by the "required openness" of a copyleft license. No doubt for many large-scale, traditional software distribution projects the same can be said. There are a few reasons for this:

1. It is an incredibly large, complex project to which most people do not have the knowledge or ability to contribute.
2. It fits a traditional software distribution model (i.e. installable, distributed as a discrete package).
3. It is so all-encompassing that it is extremely unlikely to be used as a "small part" of a larger project. Any fork of the Linux code is likely to be useful to a large part of the Linux community.

In essence, Linux is like a community-built rocket ship. It's large, has lots of knowledge and moving parts behind the scenes, and accomplishes a very difficult task that very few people are able to solve quickly or efficiently by themselves Additionally, someone could easily take the "open" blueprints for that rocket ship, make a few minor proprietary improvements, and directly sell the result making a profit off of the hard work of others.

Now let's imagine that the community came together and built a rubber band (licensed somehow under the GPL). They didn't use any special tools or processes, and it would be easy enough to rebuild the plans for the rubber band from scratch. Let's say I'm creating an incredibly complex machine that can turn aluminum into gold but needs a couple rubber bands to function. I'm going to look at the community-built rubber band and think "hey, that would save me some time". Maybe I even have a few ideas for how to make the rubber band better that I'd be willing to try out and contribute back. I get excited, maybe even start tinkering with the plans for the rubber band. Then I stop.

Wait a minute, I think, if I use this rubber band, this tiny insignificant piece of my much larger brilliant machine I will be obligated to share the blueprints for my gold-making machine whenever I sell it. Ha! I don't think so. I'll just build my own rubber band instead. It will take a little bit longer, but that's nothing compared to what I'll lose by having to share my blueprints with the world.

I've never built an open-source project so large or complex that someone else, given a little time and elbow grease, couldn't work out a similar solution in a reasonable amount of time. I mostly build small open-source libraries for Ruby many of which I completed the first version in a day or less. I like to think that I'm clever and perhaps think of a few neat tricks that would be inconvenient to live without, but I'm under no illusions. Most people in my industry could recreate my work quickly and in a straightforward manner. So how do I get people to contribute? It isn't going to be by using the GPL...people will say "screw it" and build their own version of my library that they can use without worrying about overly cumbersome licenses. No, I get people to contribute by giving it away as completely as possible (I use the MIT license, but also like the WTFPL) and asking them to contribute interesting stuff back. And you know what? It happens.

Any project I've built that has been even remotely successful has received plenty of support, patches, and help from the community. No one is required to do any of this. So why does it happen? It happens for two reasons:

1. Everyone benefits from having battle-tested libraries. It's much more sane to make a patch to an existing library than go into proprietary land where the only person you can ask for help is yourself.
2. GitHub. GitHub makes it so insanely, ridiculously easy to manage and make community contributions that contributing a patch is pretty much exactly as easy as writing a patch.

Copyleft licenses are simply not necessary for the vibrancy of the open-source community when it comes to simple libraries and, in fact, are more likely to hinder the community by encouraging the creation of multiple libraries to accomplish the same thing simply to avoid the requirements of a license like the GPL.

The Second Problem: The Groan Factor

A few months ago the Diaspora Project released its source code. While I was skeptical about the code quality and the project as a whole, I thought it might have the potential to be a real force for openness in the social networking community. Then I saw that it was licensed under the Affero GPL, and I groaned. My exact words, as posted to Present.ly that day, were:

Diaspora is AGPL, eh? Well that ENSURES that no one will ever, ever use it.

The Affero GPL is a variant of the GPL specifically designed to address software that runs on network servers (such as web applications). It requires that any server running the software (or a modified version thereof) must make available the full source code of any modifications. This is, as far as I'm concerned, a complete and total block of any usefulness the Diaspora project could have had.

Diaspora is purportedly about decentralizing the social networking space, making it so that a vast array of disparate, smaller social networks can all talk to each other. Ideally (I would imagine) the creators imagine it being adopted by companies big and small. There's just one problem. No one is ever going to build anything on top of Diaspora if any competitive advantage they might try to add (enhanced UI, additional domain-specific features) is going to have to be open-sourced as well. The license is an anchor around the project's neck, and I doubt it will ever see much adoption outside of an extremely small niche.

So what could Diaspora have done differently? They could have licensed with a very permissive license but added a clause: any modified version of the Diaspora code must remain interoperable with the "standard" release laid out by the Diaspora team. In this way, they could have allowed a thousand seeds to be planted by any company that wants to take a crack at it, knowing that these companies are license-bound to continue supporting the distributed infrastructure of the project.

This is a single but indicative example of the "groan factor" inherent with copyleft licenses. The more restrictive, the more cumbersome the open-source license is on a project, the less chance it is going to have of gaining widespread adoption. It is so easy to contribute to open-source projects these days, and is seen as a badge of pride by companies large and small. Sure, there are exceptions and there will be abuses, but by and large the community is better served by taking a pragmatic, practical approach to engendering community-driven development.

Frankie Says Relax

So what's the takeaway from all of this? The answer certainly isn't to do away with the GPL and all copyleft licenses. They have a very specific, very useful place in the community. However, an adjustment that I do think needs to be made is assuming that the GPL is the "default correct" choice for an open-source license. Just because it was the first doesn't mean its the best fit for most projects. I think that a more permissive license (such as MIT) should be the mindshare "default" and GPL is only used in situations where the copyleft restrictions will help, not hinder, the contributing community. The Ruby community (for one) has largely embraced this, and just about the only time I see GPL'ed Ruby code is when a company unaccustomed to releasing Ruby code builds a gem or when a native library a gem utilizes is under the GPL. It's one of the things that makes me happy to be a Rubyist.

Rather than fighting the problems in the copyright system by using it against itself, how about we fight it by taking away its power? Permissive licenses are a truly free way to share code because they recognize that it doesn't always make sense to open-source a derivative project. So the next time you're throwing that LICENSE file in your open-source project, think twice before you "just go with the GPL, I guess".

• Read more about A Web Developer Goes Native (with Android)

In the past week I've jumped head-first into Android development for a new Intridea project. This is my first time doing any real Android development as well as my first jump back to Java since I graduated from college. I thought it might be interesting to catalog some of my experiences developing for the platform, so here they are:

Android is built on an "Intents" system. When you want the user to perform some kind of common action, you create an intent for it and activate that intent. Different applications can hook into the same intents, allowing the user to completely customize how they handle a given action.Things I Loved

Wow, what a brilliant system. Android is built from the ground up for insane levels of interoperability between applications. It took no time at all to get a basic QR code scanning process flowing thanks to intents, and the same went for composing e-mails and opening web pages. Literally couldn't be simpler.

Activities: The base unit of an Android application is an activity. An Activity class is what holds the context for your application as well as manages on-screen events and more. One application may have many activities, divided up logically based on user actions.

Once I was able to wrap my head around the idea that any given "screen" is really more like an "activity" that the user performs, the logic of the application design really fell into place. I think this is a perfect level of abstraction for a mobile platform, and it really made it easy to figure out where to draw the line between one screen and the next.

On-Phone Debugging: My mouth actually dropped open the first time I plugged my Nexus One in and hit "Run" in Eclipse. In just 5-10 seconds my app was launching natively on my phone for me to test. Not only that, but I was still able to see logs and uncaught exceptions as the program ran. Running on the phone is also lots faster than running in the emulator.

Resources and NineScale: Google has come up with a very elegant solution to the idea of handling binary and other resources in Android projects. All of the resources in a directory are pre-compiled into a big reference file called R.java that simply contains access to every menu, image, string, and view that you've created for the application. This makes it so easy to transition between referencing resources in the XML and the code, because it all uses a similar syntax. Great stuff.

When designing views, you will often want to have image-based backgrounds that intelligently stretch to fit their contents. This is called various things in different platforms and tools (NinePatch, NineScale, 9-Slice, etc.). Google's implementation is very simple and can be done without extra plugins from any image editor (it's just a 1px border around an ordinary .png file). Once again, very cleverly designed.

The Overall Architecture: Android overall just feels like it was really put together with a lot of thought and care. Everything fits together really well and even people without hardly any desktop or previous mobile application development experience can pick it up relatively quickly. Also, the documentation is pretty extensive (though it would be great to have an even more exhaustive list of code examples of various aspects of the API).

When you're used to viewing changes to your application just by clicking "Refresh" it can definitely feel like a waste of time to have to compile and run the app. There's absolutely nothing that can really be done about this (it is a native app, after all) and Google has gone out of their way to make the process feel as responsive as possible, but it's still an unwelcome break in the development cycle for someone used to working on web apps.Things I Didn't Love Quite So Much

Where's My CSS? I'm guessing that some people will disagree with me here, but wow did I ever miss CSS when building an Android application. CSS makes it so easy to rapidly and iteratively style things. Android has a few ways to style things that definitely help over repetitive copy and paste XML attributes, but the expressiveness and power of CSS is sorely missing from building interfaces in Android.

Exceptions: When running an application in the emulator or on the phone, I really wanted a clear and easy way to view stack traces. The LogCat view on Eclipse is the way to do this, but I found a few problems with it:

1. The stack traces don't list the exception you're looking for at the top of the trace, but rather about half-way down. Takes a while to wade through and figure out what to look at.
2. When I tried to use the debugger, I never got any useful output or link-to-line type help that I expected from a fully integrated IDE. Maybe I was using it wrong, but it didn't help me out much.

Java: OK, OK, could take some flak for this one, but after developing full-time with Ruby for more than three years now, going back to Java feels like an unbearable chore. There's so much boilerplate code and I found myself really missing the simple, expressive, concise idioms of Ruby. Maybe once Mirah gets a little more mature I can at least ease that part of the Android experience.

SQLite: I know that it's the go-to solution for small, simple storage, but why on earth do mobile platforms have schema-driven data stores by default? What a ridiculously square peg to pound into the round hole of mobile data persistence. You know what the default data store for mobile ought to look like? Redis. If I had the simple data structure support provided in Redis (key-value, lists, and sets with simple combinatorial commands), I wouldn't need anything more for 99.9% of the applications I can think of. SQL is an awful, terrible fit for mobile and I hope that one day someone realizes it.

I'm glad to see that CouchDB is trying to disrupt this space a little, and I hope that the disruption continues with more datastores and more choices being available for mobile development.

Wrapping Up

It was certainly an interesting week and I've been learning a lot. Android development is starting to come more naturally (looking things up on the API docs maybe every 5 minutes instead of every 30 seconds) and I'm actually starting to enjoy myself. It's really satisfying building something that I can immediately run on my Nexus One, and I definitely look forward to working more with the platform in the future.

That being said, I don't think I would choose to develop for mobile applications as my primary focus. While mobile development is certainly rapid compared to old-school desktop development, I still don't think anything can match the ease and speed with which web applications can be developed. Since I'm ultimately more interested in ideas and solving the big-picture puzzles of applications than the low-level implementation details, web is still the place to be for me (for now).

And so we've reached the end of this rather wordy spiel; hopefully if you're a web developer you can read this and get some idea of what it would be like to dive into mobile development, and if you're already a mobile developer maybe you can tell me how I'm all wrong about everything I've just written. And maybe, just maybe, if you work for Google you'll implement Redis as the primary datastore for Android 3.0. Hey, a guy can hope, can't he?

• Read more about On Android and Custom UIs

Google’s Android has seen an incredible rise in popularity since its first handset was launched less than two years ago. Google has worked hard to earn that popularity, regularly releasing fantastic new improvements to the platform in the form of Donut, Eclaire, and now Froyo. Unfortunately, many users of the Android ecosystem won’t see these improvements for years, if at all. The reason? Manufacturers of Android handsets are building custom versions of the OS to add eye-candy and make the UI seem more attractive, at the expense of upgradeability.

HTC has its Sense UI and Motorola has MOTOBLUR. Samsung and Sony have also thrown their hats into the “heavily modified UI” ring. While these packages may serve to help differentiate from the competition, they are hammering the Android ecosystem by causing fragmentation (and yes, I do think that’s the right word). But it isn’t all their fault. One can certainly understand how, when competing against the likes of the iPhone, manufacturers would want to “pretty up” the Android experience. So I’ve got a few words for these OEMs, and Google as well.

Dear Google

I’m really happy that you’re ‘laser focused’ on the user experience for the next release. Now that you’ve got it humming at lightning speed with Froyo, it’s time to add some polish. Fantastic. But making a better stock UI isn’t the only thing that needs to happen to prevent this fragmentation.

You should be doing everything you can to prevent version fragmentation because it’s hurting developers and consumers. When people with G1s see “official Android Twitter client released” but can’t download it, they’ll get frustrated. They don’t know or care about the fact that the G1’s limited internal storage means that it can’t get the next upgrade, they only care that they’re supposed to have an Android but they can’t get the software they want.

Here’s my advice: take the feature lists of Sense and MOTOBLUR et al as a laundry list of areas where your API needs more robustness. If the capabilities of Sense and MOTOBLUR were exposed at an application level, this problem would simply disappear. You’ve built your platform to be backwards-compatible; if HTC wants to build a “Sense UI” app that changes the appearance of the UI and adds a bunch of widgets, and they want to make that only available on their handsets, more power to them. When the next version of Android comes out, it’ll all work seamlessly because they’ve simply built an app, like any other developer.

So keep up the good work on Gingerbread, I’m looking forward to the UI improvements. But also make your UI reachable by applications, provide hooks into the very guts of Android so that manufacturers and developers alike can really “make it their own” without building a custom ROM.

Dear HTC/Motorola/Samsung/Etc.

Thank you for making Android handsets. I’m a huge supporter of the platform, and the level of competition and innovation on Android phones has been amazing. Keep it up! But you’re doing yourselves a disservice by building these custom UIs that inhibit the Android version upgrade process.

Google has huge teams of people working to continuously upgrade the Android experience. You get the fruits of this labor 100% for free. I understand that as a handset manufacturer the idea of upgradeable phones isn’t necessarily the most appealing: if people can upgrade the software on their phones, maybe they won’t want a new one in 2 years! But trust me, you’ve shown that you’ll make the hardware good enough that people will want new phones.

Instead of locking down a handset to a specific Android version, create an unbeatable suite of applications that comes pre-loaded on your phone. Work on top of, instead of within, the Android operating system. Then you can leverage all of Google’s work and all of your own work to provide customers with a great experience. Work with Google to add pieces of API that will help you provide all of the value you want to provide; I’m sure Google would be happy to help as best it can.

Also, while I’m at it, can one of you please create a 4.3" handset running the stock Froyo UI sometime before November? I’d love to get a big-screen phone when my contract’s up, but I don’t know that I can handle dealing with these custom UI jobs. It’s just not for me.

Unicorns and Rainbows

I think that Android is a very important project that came along at just the right time. It has applications far beyond mobile handsets and we’ll begin seeing Android in cars, tablets, and more in the very near future. This will mean even more work will be poured into the Android ecosystem creating greater and greater benefits for everyone from consumers to handset manufacturers. All that needs to happen to take advantage of those benefits is for Google to help handset manufacturers free themselves of the idea that they need to “make it their own”.

I’m looking forward to the next 40 Android phones, and the 100 after that. I truly think that Android is going to dominate the mobile market five years from now (Apple will still have about the same piece of the pie, but Android will have displaced RIM and Microsoft entirely). So keep up the good work, but how about we all just get along in the meantime.