Eric Barnes

Open Source Marketing Tips

It’s 1 am, I’m unable to sleep and have all these crazy ideas running through my head. As I start to doze, I have a spark of genius. I think to myself this would be an awesome open source package. I guarantee others would love this. It’s so useful why hasn’t anyone else thought of it.

Over the next two weeks I spend hours and hours thinking, building, refactoring, and creating this package. I think it’s going to be the best ever. Seriously it has to be, it’s so useful.

I’m finally ready to release it. I spend at least an hour crafting the best tweet I can. Secretly wishing it will go viral, hoping others will love it, and just from one single tweet Hacker News will have it featured all day. It’s time! I hit “tweet”, sit back, and watch in great anticipation.

After the first five minutes nothing happens. Sure, some friends retweet it but it’s not gaining momentum. So now I think I’ll just wait till tomorrow when more people have seen it. But still nothing.

Where did I go wrong? Was this a dumb idea? Why doesn’t anyone like it? Is the code horrible and no one told me?

As software developers we tend to look at things from our own perspective. Assuming everyone else will see it the same way. I’ve spent all this time developing but I didn’t take those extra few minutes to really polish the marketing text. This is the big mistake. I know you are thinking it’s open source, do I really need marketing? Without a doubt yes you do!

Your readme is the first page people see when they find your package. It’s important to clearly define what the package does. List out benefits not features. Features are important but only after you’ve sold me. I need a quick overview of why your package is going to make my life easier.

The fact is you have very little time to sell someone and people do not read. They glance. If nothing stands out, they move along faster than a cheetah chasing a gazelle.

I’ve seen it time and time again where I find something that sounds cool only to have this be their main section of the readme:

  • Includes awesome package
  • Uses x design pattern
  • BDD, DDD, TDD
  • And on and on.

What does that tell me? Nothing. I really don’t care about this. Instead show me the benefits. Show or tell me why my coding life is horrible without your package.

Here are a few packages I found that I believe excel with this:

Intervention Image

Look at the demo code which is the first thing you see:

// open an image file
$img = Image::make('public/foo.jpg');

// now you are able to resize the instance
$img->resize(320, 240);

// and insert a watermark for example
$img->insert('public/watermark.png');

// finally we save the image as a new image
$img->save('public/bar.jpg');

I think to myself. WOW. That’s all it takes to upload and resize an image? I’m using this!

Carbon

Both Carbon and Intervention use the same style by letting the code speak for itself. Here is a portion of their main page:

printf("Right now is %s", Carbon::now()->toDateTimeString());
printf("Right now in Vancouver is %s", Carbon::now('America/Vancouver'));  
$tomorrow = Carbon::now()->addDay();

Dispatcher

Dispatcher is a package for scheduling tasks inside Laravel:

dispatcher

Notice how these packages explain and demonstrate why I would want to use them. It’s really that simple!

Take the extra 30 minutes and ensure your readme is clear, precise, and tells me why I should care. Be specific. Sell the benefits. Take a screen shot. Wow me.

Ian Landsman shared his slides from his talk at Microconf. Even though the video isn’t published yet the slides are great and I enjoy seeing the history of UserScape and how companies grow.

I fully agree that customer support drives sales. Reminds me of that old quote:

A happy customer tells one friend, an unhappy customer tells everybody.

Now with the internet this is so true. Especially the unhappy side.

Single Page Laravel Application

Michael Calkins asked me on Twitter the following question:

I would love to see the processes and techniques you use when designing a SPA. UI/UX, API considerations, and those things.

I thought it was an interesting question and the answer could be a benefit to the community so I’m going to do my best to answer it by outlining how I setup a brand new single page Laravel application. My last two projects have been with BackBone but I’m not going to focus on the actual framework, more so, just the setup and techniques.

Directory Structure

First I setup my directory structure by putting all my files that need to be processed inside app/assets. Then sub folders for each major area such as javascript, styles (less/sass), vendor (bower or manually copied components), etc.

From here I used Grunt, Gulp, or whatever is the new hotness and setup all the processing tasks. This will output to the public directory and I recommend spending the time on setting up source maps from the beginning. This is something I wasn’t doing and it would be so nice to have now.

First Changes

I always use Blade templates and in my master layout.blade.php I set the following meta tags:

<meta name="env" content="{{ App::environment() }}">
<meta name="token" content="{{ Session::token() }}">

I use the environment as a flag for any features that should only be in production or for testing only in development. I typically use this for things like analytics tracking or in weird cases.

The token is used for CSRF when posting from your JavaScript. Here is an example app/javascripts/plugins/ajax.js:

$.ajaxPrefilter(function(options, originalOptions, jqXHR) {
  var token;
  if (!options.crossDomain) {
    token = $('meta[name="token"]').attr('content');
    if (token) {
      return jqXHR.setRequestHeader('X-CSRF-Token', token);
    }
  }
});

As you can see this just pulls in the token and is always included on any ajax requests.

API Considerations

For both Snappy and Wardrobe I put all my controllers in the app/controllers/api folder and these are only used for javascript communication. I do recommend keeping these very thin so you can easily reuse code in the future when you need a mobile app. :)

A side benefit of putting them all in their own folder is the ability to utilize Laravel’s routing and request filters:

Request::is('api/*')
Route::when('api/*’)

Here is an example of one of my controller edit methods:

public function putEdit($id)
{
  $response = $this->post->update(Auth::user(), Input::all());

  return $this->handleJsonResponse($response, ‘Your post has been saved’);
}

Then handleJsonResponse() is defined in the BaseController and simply finds out the type of response and returns based on this:

protected function handleJsonResponse($response, $success = 'It worked!')
{
  if ($response instanceof \Illuminate\Support\MessageBag)
  {
    return Response::json($response, 400);
  }

  return Response::json(['msg' => $success]);
}

This keeps everything really DRY and easy to maintain. Also by returning the validator it gets converted to JSON and is easily consumed in your JavaScript.

JavaScript

This area really depends on the framework you have chosen on how you set it up. I only have the following two tips:

  1. Pre-seed all your primary JSON.
  2. Abstract plugins

By pre-seeding all your primary models/collections this will save you on that initial load time of fetching all the records and getting the app up and running.

Plugins are a necessary evil. I recommend always wrapping them in your own code with a simple api that way it’s easier to replace out later.

In BackBone a common pattern is to use views for this and just instantiate it when you need it. Here is a good presentation that goes more in depth on this.

CSS

I’ve struggled writing good clean CSS. If I’m being completely honest a lot of times I end up with a mess on big projects. It starts off great but then a new feature here, a new feature there, and wham! a mess. :)

If I was starting a new app today I would follow an existing style guide such as the one GitHub published or Smacss.

Since I’m not a CSS wizard I do not want to steer anyone in the wrong direction. However, I do have one tip to share and that is use slightly obtrusive javascript. What this recommends is adding a js- class to all elements your JavaScript interacts with:

<a href=“#” class=“js-edit edit”>Edit</a>

On small apps this is over kill but if you plan on maintaining this for years to come this is very helpful for refactoring and noticing when selectors are used elsewhere.

UI/UX

I could be off base with this, but I feel the terms UI/UX are a little open for interpretation. If I ask 5 engineers to define it off the hip, they all would give me different answers.

To me this is the most important area of any application and I feel UI/UX is what drives emotion and leads people to an action. Most engineers are generally week in this area. If thats you then your goal should be to get everything related to the design uniform and plan from the beginning for adjustments. This area is rarely static.

The design and usability is so important in any app. No matter if it’s open source or commercial this is where users spend 100% of their time. Users do not care about your code and all your fancy design patterns. They have a goal in mind and need the simplest and easiest way to achieve it. This is what makes or breaks a product. It’s also the hardest to get right.

The closer you are to the development of a feature the harder it is to notice little nuances. I’m no different. Anytime I complete a new feature I always ask for feedback before deploying. 9 times out of 10 the reviewer will spot something that I totally missed.

To reiterate, if you are week in this area get everything uniform and bring an expert in. If you don’t have the means of getting an expert then plan on spending lots of time thinking and getting feedback.

Is it really different?

I do not believe it’s that much different from building a “traditional app”. Instead of one you now have two, a backend for api endpoints and auth then the front-end or client for the end user.

Over a thousand words later I hope I’ve answered Michael’s question without opening up many more. :) Nevertheless if you do have questions don’t hesitate to get in touch.

Alyssa Mazzina writes:

Sleep is generally the first thing we sacrifice when we start to get busy. Eight hours of sleep is a full third of my valuable time! Come on! Ain’t nobody got time for that!

This post is a great reminder not only to founders but also developers. I struggle with getting enough sleep and I’ve been in this vicious cycle of staying up late during the week and then Friday night sleeping like 9 or 10 hours. I need an app that totally locks me out of my computer after 9pm. :-) When you first install the app it has my wife set the unlock code so you could access in case of emergency. But be honest how many emergencies are there between 9pm and the time you wake up. :)

In the end change is hard!

Ian just made a post sharing 9 tips for working remote with kids. I thought it was a great list and the tip for making exceptions reminded of a great memory I got to share with my youngest daughter a few months ago

I couldn’t fit everything in the tweet but she came running into my office with a princess dress on and batting her eye lashes telling me I was cordially invited to a royal ball. It was unforgettable for me and a memory I will cherish forever.

These are the quick moments that I wouldn’t get to experience first hand if I didn’t work remote. While my kids are small I can’t imagine working in an office. They grow up to fast and then it’s gone. No turning back the clock on what you should have done.