Selling Open Source
The past few days have proven interesting and encouraging. I’ve received many thoughtful comments and hopeful messages from users. However, there is some misinformation surrounding the timing and my motivations for making Briefs open-source. This post is the first of two I hope will clear up some confusion. First, I want to tackle the how and why I released the source for Briefs.
It was Always Open Source
Let’s get this out of the way: Briefs was always open-source. From the first release in September 2009, I announced that the current and future releases would all be open. I selected a modified MIT license for the first iteration because I wanted anyone to use the code how they saw fit. No strings attached and this solved the distribution problem perfectly. It was a framework for developers and any one could install it on their device.
Even before September, many designers were approaching me with a dilemma: how could they use the app if they were unable to build it from source? In that question, a version of Briefs for the App store was born. So, Briefs was open first; a for-pay build second.
With the App store version, designers could purchase a pre-built version that was dead simple to install on their device. (it was also an easy way for developers to give money to a project they found useful) The version I submitted to Apple in May was built as a way to get the app in a designer’s hands.
The Revised License
Many have already noticed that the original license for the Briefs.app source has been modified in the 1.0 release. In particular, I added lines protecting the Briefs trademark and the following clause:
“The Software and/or source code cannot be copied in whole and sold without meaningful modification for a profit.”
The complete license can be read here.
I had planned to detail the various sources that served as inspiration but, as luck would have it, a slashdot commenter has already done that for me. The commenter posits that the license is not “Open Source”, “Free Software” or “DFSG-free.” The basis of their accusation is that I don’t use an existing open-source license. They offer the addition of the above clause as proof that I hate freedom, apple pie and the American Way™.
Why do I Hate Your Freedom?
The irony of the slashdot comments is rich. Not only do I offer two separate embeddable libraries—one for reading briefs, another for running them—I do so under a license without the above modification clause. The truth is, I want people to use the .brieflist format. I envisioned it not only as a prototyping format but also as a UI specification document. Imagine if you could hand a developer a brief instead of a Photoshop mockup?
If you explore the briefs.app project, you’ll notice the revised license only covers the UI (e.g., view controllers, local storage, etc.) of the app. None of the core pieces of the Briefs framework are covered under the more restrictive license (since they’re part of sub-projects in other repositories).
I tried to use a scalpel when applying the clause.
Why the Clause Matters
You might ask, what essential liberty am I excluding by adding the modification clause? Ironically, nothing. My motivation for adding the clause was to prevent a scenario where someone would upload a carbon copy of my application to the App store, under their name, with their price. If I charged $15, someone could ask $8 and undercut me with little effort on their part. If I allowed that to happen, it would destroy my ability to sell the app. Then I’d have to make the choice to either sell or open-source the app. I wanted to do both.
However, this entire train of thought is moot if I can’t sell the app in the first place. Currently I’m only withholding your right to submit this app to Apple and wait three months not to be accepted or rejected. I’m such a greedy bastard. Shame on me.
The New Open Source Business Model
The license, despite opinions, is actually a professionally engineered piece of legalese that allows you to open-source your app and still sell it. A lot has been said about Apple’s walled garden but since they control distribution, a majority of the market can’t install an app from source. That sucks if you’re a user, but fortunate if you’re a developer that wants to open-source your application.
Most assume you can’t sell open-source software because no one would pay money for something they can install for free. Free software is practically synonymous with liberty and no cost. When the App store, the equation changed. Interested parties now have the liberty to examine or modify (and re-install if you pay Apple) an application while developers charge a fair price for their applications. Freedom for users, beer money for developers.
Needless to say, I’m excited about the prospect of the new model. Imagine how powerful this would be for budding developers? What if you could look under the covers of your favorite apps? What could you learn?
Even users would see a direct benefit. Jeff LaMarche talks about coding as if everyone is watching and with an open-source business model everyone could be watching. Vanity alone would dictate better engineering!
Introducing the Rhyne Open Source Software (ROSS) License
When I asked Jonathan Rhyne to author a new open-source license I provided a simple wish list:
- Royalty free use in commercial and non-commercial projects
- Attribution should be required
- Prevent people from submitting an unmodified copy to Apple for sale
- Simple language
The result is a modified MIT license with BSD-style attribution that is compatible with the Apple’s distribution model. It gives the discerning developer peace of mind knowing that your brand and trademark are protected, while freeing them to share the coolest bits of their implementation.
This license is my gift to you. Take it and use it.
You Still Need an Attorney
There is some fine print. Obviously this license, as with most open-source licenses, has not been tested in a courtroom. I cannot guarantee it’ll hold up in court and we live in a world where some stooge will try to find a way around it. When that happens, you’ll want an attorney.
Jonathan did a spectacular job bringing classic open source licenses into the modern age. He’s a closet Apple lover and he knows the answer to the ultimate question1. If you’re an app developer, you want him on your side. Who else has an attorney that does consultations over FaceTime2?
He’s even on the Twitter.
1 Which ship would win, an Imperial Star Destroyer or the Starship Enterprise? ↩
2 Of course, he isn’t as handsome as his older brother. ↩
Update on Briefs
It has been three months since I last threw myself upon the court of public opinion. I have waited three months for a resolution—any resolution—on the matter of Briefs’ admission into the App store and have grown weary waiting for a response. Many have asked where things stand, so I decided to grab the megaphone once again.
Executive Order
Before showering the interested few with details, I’ll summarize where things stand as of today. First, the app is not available on the App store and I have no reason to believe it will be anytime soon. That is not, however, for lack of effort by a great many inside of Apple.
At WWDC I was connected with two developer evangelists and eventually the director of the App store to discuss Briefs’ prospects. All three were very encouraging and helpful. This was in addition to several Apple engineers detailing their use of Briefs for company efforts. I left the conference with hope that differences could be resolved and Briefs would be up for sale.
That was until a few weeks later, when I was told (by the director himself) that the review had reached the “executive level.” Considering he reports directly to an Executive Vice President within Apple, I have every reason to believe him. Unfortunately two and half months have transpired since reaching the executive review. (and what a two and a half months it has been for Apple executives!) I have not completely given up hope, but it is time to move on.
Moving On
Many have asked about development status, including a version for the iPad and a visual builder for .brieflist files. I’m a new indie of four months and trying to feed a family. I have already poured hundreds of hours preparing Briefs for a public release while simultaneously bootstrapping my consulting business with Jeff and Dave. With the status unknown and Apple openly opposing the strategy behind Briefs, it has become hard to stay motivated.
So instead of trucking along, and growing more resentful of the project, I’ve decided to take a break. And to cool the sting, I’m releasing the 1.0 code base to github today.
1.0 Source Available Today
The completely redesigned user interface. The underwear-laden app icon designed by IconFactory. The brief:// and briefcast:// url schemes. It’s all there, including a few bits of code I actually take pride in releasing to the public.
Also, if you were having problems getting scrolling actors to work, all of the fixes are in the new code base. Everything should just work. As always, email me with any questions or problems you’re having.
The Road Ahead
I am not finished with Briefs and I would like to find a way to devote more time to it. I’m considering a lot of ideas—including a Kickstarter project to fund iPad development. I still have some good ideas for the platform and I hope to get back to them in good time. However, it’s time to focus on other work and projects that can get into the App store.
In the meantime, feel free to email me with questions, comments or even links like this. It never gets old hearing how others are using Briefs. It still amazes me that I’ll never know everyone who’s ever used it and doubtful that I can thank you all in person.
Thanks. If it wasn’t for folks like you, I would have given up long ago.
In Loving Memory
She’d tell me I was acting old, then giggle at the length of my sideburns.
She’d rail on Sarah Palin, then build a mosque in her front yard.
She’d eat more hot dogs than any grown woman should.
If only, she were here.
She was care-free and irreverent.
She was unforgettable.
Bookish and charming.
Beautiful.
On June 16th, 1999 she was a month into her twenties,
When small piece of candy, coated in peanut oil, claimed her life.
I remember driving to the hospital.
I remember the doctor shaking their head.
Everything stops when they unplug your friend.
I squeezed her mother and sister’s hand.
I couldn’t bear to look at her father.
I wept openly.
On August 16th, 2010 I pledged $100 in her memory.
For her family.
For families with allergic children.
For my six year old niece.
—
A parent should never bury their child. Help support Amy Jane Gruber and others like her. http://www.foodallergywalk.org/goto/amyjanegruber
Almost on the App Store
I’ve noticed a lot of recent comments bouncing around Twitter about Briefs and some misinformation I hope to clear up. In addition I’d like to share some new things related to Briefs and talk about the future.
Version 1.0
It’s been said that version 1.0 will try to kill you. Funny thing is that 1.0 will not be the first public release of Briefs and it still tried to kill me. The first release was as a developer-only open-source framework at C4 last September. But I decided early in development that version 1.0 would be a general release to the App Store. iPhone app distribution is limited to the App store, it was the only way one could use Briefs if they had not paid $100 to become an iPhone developer.
In short, I could continue to provide open-source software to developers and charge others who wanted to use it. Likewise, for designers and others who wanted to try their hand at creating something on the iPhone, they could pay $15 for an app instead of the $100/year. It was a sweet deal for everyone.
Not an App Framework
But that’s where things started to break down. I’ve presented Briefs in front of several audiences since C4 and without fail, at least one person asks: “Is Briefs an app framework?” I always answer it the same way: “Not at all.” My reasons are simple:
- I want it to be simple.
- It’s for design prototypes (they are shallow on purpose).
- I wanted to make as few assumptions possible about how one designs an app.
In other words, the purpose of Briefs is to better understand the design of your app. I tried to find the most concise way to articulate your design and then get out of the way. I couldn’t do that if Briefs was an app framework.
The Power of Creation
Regardless of my answer and despite the fact that a brief makes for a very limited app experience, (seriously, no data entry, no network connections — just images!) people still insist on labeling it an app framework. Unfortunately, I’m afraid the Apple reviewers believe the same thing and this misconception is causing a stir. Last week, after initially submitting on May 7th, I received a phone call from Apple to update me on the status of my submission.
The gentleman on the phone was courteous and polite, but his message was blunt. While I had not been officially rejected (at least, not yet), he asked me some questions and hoped to manage my expectations. Based on the information available to him, the reviewers believed Briefs contained a non-Apple interpreter and the first team initially rejected it for non-compliance with section 3.3.2 of the iPhone Developer Agreement. I’m still waiting to hear their final decision.
Before I go any further, I want to make myself clear. I do not assume malice is at fault and this is not another developer rant about Apple’s App store policies. I believe this is merely a misunderstanding.
Communication Breakdown
Allow me to explain. First, Briefs has a lot of moving parts and my documentation, until recently, has been lacking. The current workflow is, at its essence:
- Write a
.bsscript on your Mac - Compile that
.bsscript into a binaryplistwith a.brieflistextension, on your Mac. - Copy that binary
plistonto your phone. (there are several ways)
When the Apple reviewers saw bs chunks of code littered throughout the documentation, it’s not hard to see how they thought I was running a custom script interpreter on the phone.
So, after my 15 minute phone call with Apple, I composed an email to the reviewer on the phone (at his request) and explained the process in similar detail. I also articulated that I was compliant with 3.3.2.
3.3.2 An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
Above is the 3.3.2 clause of the developer’s agreement that the reviewer kindly provided in an email. The emphasis was added by me, to clarify my point. The final statement is key, because in Briefs 1.0, a brief can be downloaded to the phone and run inside of the app.
Below is a code excerpt from Briefs that is responsible for loading a downloaded brief into memory:
+ (NSDictionary *)dictionaryFromData:(NSData *)data
{
CFStringRef errorString;
CFPropertyListRef propertyListRef = CFPropertyListCreateFromXMLData(kCFAllocatorDefault,
(CFDataRef) data, kCFPropertyListImmutable, &errorString);
if (errorString != NULL) {
NSLog(@"The following error occurred while converting the incoming data: %@", errorString);
return nil;
}
else return (NSDictionary *) propertyListRef;
}
For the non-technical reader, I’m taking binary data I received from a network connection and converting it to an NSDictionary object. (for the technical reader, this is a convenience category I created on NSDictionary) Once in this representation, Briefs can render the brief to the user.
In other words, I use a public API provided and documented by Apple to load the brief into memory from a network connection. When reading a brief from local storage, I use the + dictionaryWithContentsOfFile: method built into NSDictionary. Also public, documented and provided by Apple.
Forest and the Trees
I believe this is a miscommunication and one I hoped will be resolved as a result of my email exchange with the Apple reviewer. Perhaps this post can provide further clarification. Legally, Apple has done nothing but exercise their legal right (granted by my acceptance of the developer agreement) to review my application and hold it against the terms of the agreement. However, I believe they are missing the larger picture.
The purpose of Briefs is to make better designed apps. By using the design on the phone and quickly iterating, you can better pair your app with the device. You’re in a better position to understand the iPhone and its capabilities if you use a Brief first. And if you want proof of its effectiveness, just look at the recently released Bistromath from Black Pixel. The designer told me that Bistromath was the first app he designed entirely in Briefs before starting development. Briefs isn’t about rapidly building apps —in fact the opposite. It’s about taking your time and carefully considering the design before building. That is right in Apple’s wheelhouse.
I want to take Steve Job’s comment that they “make mistakes… but we correct them” at face value. The language of their agreement was written by lawyers, not engineers. And technology is still not well understood by lawyers. My brother is a good attorney, who we use for our MartianCraft legal needs because he understands technology. He’s 26 and not at all representative of the broader legal field. Therefore, it’s expected that Apple will not foresee every impact of the (often broad) language of their developer agreement. What Apple can do (and often does) is amend the terms of their agreement when there are unintended implications of the language. In this case, 3.3.2 is restricting an app that would improve the apps on the platform.
So, the language must be challenged. In fact, challenging the legality of the agreement is precisely how our legal system is intended to work. It’s simply not enough to complain, you have to push back with apps. That was the point of my first post on this blog. In Briefs, I’ve posed an app that challenges section 3.3 of the agreement that is intended to improve the quality of native apps, not degrade it.
Looking Ahead
The value of Briefs is well understood by developers already using it to improve their apps. It has also brought me personal success well beyond what I could’ve imagined. I have big plans for the iPad, Mac and future iPhone releases. However, if Apple ultimately rejects Briefs it will affect that direction.
Assuming the worse, I refuse to fold. The improvements I’ve made will be pushed out to the github repository regardless if it appears on the store. Briefs will continue to live on as a developer tool, but not in the grand manner I envisioned. I believe it has value to non-developers, but there is simply no other way to put it in their hands.
The New Shiny
This post was supposed to be a celebration. I was going to show off the redesigned website, with a new documentation section. I wanted to share my first foray into screencasting and let newcomers see what they’ve been missing. I wanted it to be a victory lap, instead of a concession speech.
Since this is my official 1.0 “release” post, I want to close this by thanking those who’ve helped me get to the finish line:
Jose Vazquez wrote the first real brief (hint: it’s the sketch you see everywhere on the site and in the video) and the first version of the BS parser. He wanted an app like Briefs and he convinced me to write it. He then convinced me to submit a Blitz proposal to C4 after I told him he was insane. Next to the Architect, he has been my biggest supporter.
Chris Clark beat the crap out of the early versions of Briefs and found more bugs that I care to remember. He understood the potential early and pushed me to make it better. He also re-wrote the scene transitions code because he didn’t like the way I named them. I appreciate his immense amount of help and his patience with my love for the ternary operator.
Jonathan “Wolf” Rentzsch gave Briefs an audience, but more importantly he gave me a voice. Without C4 I would not be a Cocoa developer and I’d still be working for BigCo government contractor. I am who I am today because of Jonathan. One word of advice: Never ask him about schedule unless you want to go first!
Alex Vollmer wrote the definitive article on getting started with Briefs back in January. I always have his post loaded in Safari on my iPhone in case I need to explain how it works to someone. He is also the author of a killer cheat sheet for Briefs that has been updated for 1.0 and is included in the newly released starter kit.
Chris Wetterman found a crasher and a gigantic memory leak that artificially limited the number of scenes one could have in a brief. He did this four days before I was set to submit to Apple. His methods are obsessive, a little insane and absolutely brilliant! He made the code base better when I needed it the most.
Craig Hockenberry, John Gruber, Matt Drance, Brandon Walkin and Jason Snell gave me untold amounts of encouragement, words of wisdom and motivation. Thanks for your patience while beta testing an app with less than complete documentation.
Finally, a sincere thanks to every person who has ever used Briefs. You’ve made it a success and keep me motivated every time I open Xcode.
The Breaking of the Fellowship
In 2007 my wife and I celebrated our third anniversary by spending a week in Chicago, Il. We chose Chicago for several reasons — one of them was C4, a small indie Mac developer conference. I recently had completed some freelance Mac development and had dreams of building Mac products for a living. I was intimidated. The emphasis on design drew me in and I used many indie Mac programs in my daily work. MarsEdit, NetNewsWire, VoodooPad, Transmit, etc. The developers had achieved a larger-than-life status in my universe and for one weekend, they would be in the same room in a smaller setting. It was too good to resist.
So, in Spring of 2007 I summoned up the courage and registered (back when C4 didn’t sell out in hours). I wanted to see this world up close and find out if I had what it took. Needless to say the following August was a revelation. Not in the humbling way I thought it would feel. Instead what I discovered is the developers were just like me. Simple people, with computer science backgrounds and a passion for great software. Meeting them, and seeing them in the wild proved to me that I could be one of them. That was C4’s gift to me.
Yesterday, Jonathan Rentzsch announced he’s shuttering the doors on C4. The conference that forged me into an indie (both figuratively and literally — Briefs was released at the last C4, catapulting me on that trajectory) was no more. That it is gone is painful enough. However, Jonathan’s reasons for closing down C4 is what stings the most.
The Respect
First let me state, unequivocally, how much I respect Jonathan and his choice to stick by his principles. I cannot imagine the agony over making this decision. Second, I’ve had the pleasure of discussing 3.3.1 with him in person and his argument is neither shallow or misdirected. I challenge anyone to engage him in a discussion on the topic and not second guess their own opinion afterwards. Especially those who think he’s overreacted. It would be too easy to dismiss him as a curmudgeon and disregard his message.
His gripes are valid and they’re not with Apple, but with the community of developers surrounding Apple. The same community he has served and helped grow. If you dismiss his point, you only make a stronger case for it.
The Dilemma
What Jonathan would like to see is simple: that developers ask more of Apple. Don’t let them get away with this “war on Computer Science,” as he refers to it. The App store is too restrictive and Apple is working to restrict it more. They want to dictate the manner in which you write for their platform. Section 3.3.1 of the SDK agreement gives them that latitude. It’s not about what gets in and what doesn’t get into the store. What matters is that Apple calls the shots and can do so in a opaque manner with singular discretion.
Despite these facts (and demonstrated behavior), there are developers queuing in the streets for an opportunity to write for the platform. This developer included. It’s a great platform with tons of potential. Potential we have yet to see realized.
But it is impossible to criticize the platform when Apple is the gatekeeper. And a petty gatekeeper, with no sense of humor. Just ask Ellen Degeneres. How should a developer who has invested months, possibly years of time in the platform effectively criticize Apple for its policies? How can they do it without fearing removal from the store?
Here in lies the rub. iPhone developers are weary about criticizing a capricious distribution channel with absolute control. This has led to an uneasy silence regarding 3.3.1 that finally wore Rentzsch down.
The Dreamers
I now look out at the community I love and see a divided house. There are those in the community that look down on me as merely an iPhone developer. They lump me in with the one-hit wonders and wannabe stars who only seek App store glory. I offend those who object to Apple’s policies because I implicitly defend those policies when I don’t lay down my UIKit in protest.
However, I choose to see things a little differently. There are two apples within Apple, Inc. The first is building a series of barriers and partitions that will eventually undo the company if it fails to cede control. The second is building the computer science of tomorrow.
I dream of a day when the second group will drive the first group out of Apple. But I recognize the second group is just as likely to jump ship when the first group finally destroys the company. And when the mass exodus of the second group occurs, this developer will follow them wherever they go.
Until either scenario comes to pass, I find it in my best interest to work the problem from within. In fact, Briefs should be considered my first missile launched at the bunker called 3.3.1. When I publicly protest it will not be an abstract argument, but one based on a concrete example.
I don’t have the luxury of ignoring the platform until Apple gets their act together. Instead I have to shape the barriers the best way I can: by challenging them with apps. Find out what rules can be bent and what can be broken.
The Message
If I could say one thing to Jonathan it would be this: Don’t take my silence as a willful act of contrition, but as a steeled act of resolve. In fact, I think there is no better time for developers to have a little C4 in them than the present. Jonathan, thanks for the memories; Your work will be missed, but your legacy will endure.
Sandy Feet (via flickr)
