Creating an Awesome Open Source Community

An active community is probably the most important necessity for open source software projects. Leaders of open source projects should actively satisfy the members of their community because without them their project is not worth much. Makes sense right? I recently came across a PhD thesis called “Factors Influencing Participant Satisfaction with Free and Open Source Projects.” If you’re interested you can read the entire thesis here. In summary, the research question the thesis addressed was: “What influences community member satisfaction with free and open source software projects?”

The Hypotheses

After many interviews and surveys, the following hypotheses remained valid:

  • High quality and relatively frequent developer communication lead to better satisfaction.
  • A positive relationship exists between the amount of participation and participant satisfaction.
  • A positive relationship exists between process openness and participant satisfaction.

There were some others too but these cover the main points.

Ways to Create an Awesome Open Source Community

The paper ends with several recommendations for Open Source projects that will, in theory, create an awesome open source project and, most importantly, an awesome open source community.

Based on my involvement with several open source projects, both big and small, I agree that if a project has these 6 characteristics it has a good chance to become popular. It all comes down to the user base. In my view there is no better accelerator than a happy and involved user base.

The List

  • The “About” page should include information about what types of contributions are most needed. This page should also clearly explain how community members should go about contributing.

This is pretty self-explanatory. If you want people to help you need to tell them how to help.

  • Make sure to acknowledge and celebrate contributions. This will make people who do contribute feel appreciated and motivated to continue and help more.

I’ve made several significant contributions to open source projects and it’s always a little irritating if the Pull Request is merged with no comment of appreciation like “Thanks for your help.”

  • Monitor the project’s email discussion list and/or forums and answer questions — particularly those from newcomers to create a great first experience.

There’s almost nothing more annoying than emailing a list with many members and never getting a reply. I’ve done that several times. It really creates a welcoming environment when a member of that projects community takes a minute to reply to your request.

  • Provide information to the project’s about the future development, aka roadmap.

For free and public open source projects there’s little reason for the lead developers to hide their plans. Some might fear that other projects will borrow “steal” their ideas but that’s not a good reason. A roadmap shows commitment, dedication and organization.

  • Provide documentation that is up-to-date and clear, especially the more complex components.

Reading through documentation that is old, outdated, and written for who knows who isn’t fun for anyone. Creating a group in your open source community that focuses on writing clean documentation is a brilliant idea.

  • Finally, identify what barriers participants encounter when making a contribution to the project, and take steps to decrease or eliminate them.

Making it easy for people to become involved is important. Don’t assume everyone knows the process to submit Pull Requests.

What do you think are the best practices for creating successful open source communities?

High Performance Ghost Configuration with NGINX

Ghost is an open source platform for blogging founded by John O’Nolan and Hannah Wolfe. It’s a node.js application and therefore works great in conjunction with nginx. This guide will will help you create a high performance nginx virtual host configuration for Ghost.

After seeing that tweet I decided to make my own configuration guide for running the Ghost CMS with nginx.

 

Ghost is a node.js application that runs on a port. We can configure nginx to proxy to this port and also cache so that we don’t need to rely on express, the default node web application framework.To start we need to tell nginx what port Ghost is running on. Define an upstream in your domains virtual host configuration file.

upstream ghost_upstream {
    server 127.0.0.1:2368;
    keepalive 64;
}

This tells nginx that Ghost is running on 127.0.0.1:2358 and sets the connection to last 64 secconds to avoid having to reconnect for every request.

Proxy Cache

We want to cache responses from Ghost so we can avoid having to proxy to the application for every request. The first step to do this is set a proxy_cache_path. In your configuration define the cache. The configuration below creates a zone that is 75 megabytes, and removes files after 24 hours if they haven’t been requested.

proxy_cache_path /var/run/cache levels=1:2 keys_zone=STATIC:75m inactive=24h 
max_size=512m;

Server Block

Now we can start the configuration for the domain that will be serving your Ghost blog. Note, if your using SSL/TLS for your blog you will want to use the configuration towards the end of this guide.

1) Location block for blog page requests:

This configuration will cache valid 200 responses for 30 minutes and 404 responses for 1 minute from the previously defined upstream into the STATIC proxy_cache. We also want to ignore and or hide several headers that Ghost creates since we will be using our own. In addition to the nginx cache we will also be caching the pages in the browser for 10 minutes, expires 10m;.

location / {
        proxy_cache STATIC;
        proxy_cache_valid 200 30m;
        proxy_cache_valid 404 1m;
        proxy_pass http://ghost_upstream;
        proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
        proxy_ignore_headers Set-Cookie;
        proxy_hide_header Set-Cookie;
        proxy_hide_header X-powered-by;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        expires 10m;
    }

It’s also helpful to add a header to your page requests that tells if the request hit the nginx cache. This can be done easily with add_header X-Cache $upstream_cache_status;.

2) Location block(s) for static file requests like css, js and images:

We are going to tell nginx where to find static files like css, js and images since the node.js powered Ghost application is on the same server as nginx. To do thise we need four location blocks that point to the location of images folder, assets folder, public folder, and scripts folder. We will cache these static fiiles with expires max; so they remain cached forever in the users browser. This is safe to do since ghost appends a version query string that updates when node.js is reloaded/restarted.

Note: When changing your Ghost theme you will need to change the alias path in the location /assets nginx block.

location /content/images {
        alias /path/to/ghost/content/images;
        access_log off;
        expires max;
    }
    location /assets {
        alias /path/to/ghost/content/themes/(theme-name)/assets;
        access_log off;
        expires max;
    }
    location /public {
        alias /path/to/ghost/core/built/public;
        access_log off;
        expires max;
    }
    location /ghost/scripts {
        alias /path/to/ghost/core/built/scripts;
        access_log off;
        expires max;
    }
3) nginx Location Block for Ghost Admin Interface

The administrative interface should definitely not be cached. The location block below applies to the backend and signout page. It defines the establed ghost_upstream backend and sets cache headers to ensure nothing is cached. Most importantly, note that we are not defining any proxy_cache settings.

location ~ ^/(?:ghost|signout) { 
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://ghost_upstream;
        add_header Cache-Control "no-cache, private, no-store,
        must-revalidate, max-stale=0, post-check=0, pre-check=0";
    }

Full HTTP NGINX Configuration for Ghost.

If you’ve followed along you will now end up with a working nginx configuration that looks like this:

server {
   server_name domain.com;
   add_header X-Cache $upstream_cache_status;
   location / {
        proxy_cache STATIC;
        proxy_cache_valid 200 30m;
        proxy_cache_valid 404 1m;
        proxy_pass http://ghost_upstream;
        proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
        proxy_ignore_headers Set-Cookie;
        proxy_hide_header Set-Cookie;
        proxy_hide_header X-powered-by;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        expires 10m;
    }
    location /content/images {
        alias /path/to/ghost/content/images;
        access_log off;
        expires max;
    }
    location /assets {
        alias /path/to/ghost/content/themes/uno-master/assets;
        access_log off;
        expires max;
    }
    location /public {
        alias /path/to/ghost/core/built/public;
        access_log off;
        expires max;
    }
    location /ghost/scripts {
        alias /path/to/ghost/core/built/scripts;
        access_log off;
        expires max;
    }
    location ~ ^/(?:ghost|signout) { 
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://ghost_upstream;
        add_header Cache-Control "no-cache, private, no-store,
        must-revalidate, max-stale=0, post-check=0, pre-check=0";
    }

}

SSL/TLS Configuration for Ghost Blog

You may want to server your blog over HTTPS with SSL/TLS. First thing you should do is update the URL in the Ghost config.js file.

The nginx setup for usin SSL/TLS for Ghost requires several additional configurations. A full sample configuration is below. I will highlight the important differences.

The first several lines of the nginx configuration below establish and optimize HTTPS connections. You can use SPDY and additional settings like spdy_headers_comp, keepalive_timeout , ssl_session_cache, and OCSP stapling. Here I’m going to assume you know what those are since the purpose of this guide is to talk about Ghost.

In the location / block it’s very important that you include proxy_set_header X-Forwarded-Proto https; or else when you go to load your Ghost blog you will receive a redirect loop. You’ll need the same thing in the location ~ ^/(?:ghost|signout) { block.

server {
   server_name domain.com;
   listen 443 ssl spdy;
   spdy_headers_comp 6;
   spdy_keepalive_timeout 300;
   keepalive_timeout 300;
   ssl_certificate_key /etc/nginx/ssl/domain.key;
   ssl_certificate /etc/nginx/ssl/domain.crt;
   ssl_session_cache shared:SSL:10m;  
   ssl_session_timeout 24h;           
   ssl_buffer_size 1400;              
   ssl_stapling on;
   ssl_stapling_verify on;
   ssl_trusted_certificate /etc/nginx/ssl/trust.crt;
   resolver 8.8.8.8 8.8.4.4 valid=300s;
   add_header Strict-Transport-Security 'max-age=31536000; includeSubDomains';
   add_header X-Cache $upstream_cache_status;
   location / {
        proxy_cache STATIC;
        proxy_cache_valid 200 30m;
        proxy_cache_valid 404 1m;
        proxy_pass http://ghost_upstream;
        proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
        proxy_ignore_headers Set-Cookie;
        proxy_hide_header Set-Cookie;
        proxy_hide_header X-powered-by;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto https;
        proxy_set_header Host $http_host;
        expires 10m;
    }
    location /content/images {
        alias /path/to/ghost/content/images;
        access_log off;
        expires max;
    }
    location /assets {
        alias /path/to/ghost/themes/uno-master/assets;
        access_log off;
        expires max;
    }
    location /public {
        alias /path/to/ghost/built/public;
        access_log off;
        expires max;
    }
    location /ghost/scripts {
        alias /path/to/ghost/core/built/scripts;
        access_log off;
        expires max;
    }
    location ~ ^/(?:ghost|signout) { 
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Host $http_host;
        proxy_pass http://ghost_upstream;
        add_header Cache-Control "no-cache, private, no-store,
        must-revalidate, max-stale=0, post-check=0, pre-check=0";
        proxy_set_header X-Forwarded-Proto https;
    }
}

Questions or comments? Post below!