Take a listen and please get in touch if you have any questions or thoughts about worker co-operatives in hi-tech.

It is an exciting time at Brierwood Design. We’ve settled into our office location in Westboro, and we’ll be taking the entire team down to WWDC 2012 in the next few weeks. We have some excellent clients and some great products to be launched in 2012.

We hope you enjoy our new site.

Thanks to Claus for his great work. If you are starting a new project, I would go with ILBitly, but BRBitly is another option.

The setup and installation went very well except when I tried to deviate from the recommended directory structure at which point I had to open a support ticket with my weird error and got an excellent response that was 100% on the money. I don’t want to repeat a lot of the basic setup instructions because I think that has been handled adequately by the dotcloud django documentation and by Ken Cochrane’s excellent blog post Deploying My Django Application to Dotcloud.

The thing that I wanted to give people was a starting repot with the correct layout and setup that worked for me. Most of the instructions and commands are included in the README for my public bitbucket repot dotcloud_starter. The project is based around using django-piston and even includes a working sample app with fixtures.

Please note that this project makes several mildly opinionated assumptions to get started quickly: use sqlite for DB, use south for migrations, use piston for mobile API. Please feel free to drop me a note or comment if you find this useful.

Overally, I was quite impressed with the dotcloud offering and the flexibility of the services which you can mix and match. I may extend this starter project in the future with support for push notifications or even redis pub/sub. We’ll see — I also want to use this for some real-world examples.

Good luck. I’m also hoping to try out ep.io soon or apphosted.

Overall, the setup and installation went relatively smoothly, but definitely a few rough edges. Ken Cochrane has a nice blog post about getting started with an existing blog project My Day in Gondor.io. I used that post extensively.

I started with a brand new project and used familiar tools such as virtualenv and pip. This was my first new project since Django 1.3 was released so there were some hiccoughs around the new static files module. The other blog posts and gondor docs cover things pretty well, but what I thought was missing was a simple starting repot with the directory layout and setup that worked for me. To this end, I created a public repot on bitbucket: gondor_starter.

Please note that this project makes several mildly opinionated assumptions to get started quickly: use sqlite for DB, use south for migrations, use django-tokenapi for mobile authentication. You can find more documentation on this in the project README. Please feel free to drop me a note or comment if you find this useful.

Good luck. I’m hoping to try out dotcloud next and paired with piston.

Shawn and I formed a team to create an application using the Yellow API (one of the official APIs) and Urban Airship (an unofficial but also very useful API). The Yellow API provides various business searches including a location aware search. The idea for the app was pretty simple: you want to find a nearby business such as a local coffee shop and would like to get a recommendation from one of your friends who knows both YOU and the local business.

The flow through the app is pretty simple:

1. You enter a search term for a local business such as “coffee shop” and view the results from Yellow API on a map
2. You decide to ask for help from one or more of your friends by selecting them from a list within the app.
3. Your friend receives an instant notification popup on their phone which indicates you are asking for help to find a coffee shop.
4. Your friend agrees to help and is immediately viewing the exact same map and local coffee shops that you are seeing on your phone.
5. Your friend selects one that he would like to recommend and hits “Send recommendation”
6. You receive an instant notification on your phone with the recommendation from your friend. You can view the business on the map and proceed to get directions etc.

It was a real challenge to get this app working over the course of the day which seemed to fly by. Fortunately, we did get a working prototype and were able to demo it at the end of the day. The judges seemed to like the app and the idea and awarded us 2nd place. It was a great result and we were thrilled to get a new Android phone.

Congrats to Jevin and Brad for their awesome 1st place web app “Reservely” (which you should definitely check out).

We haven’t figured out when/whether/how we are going to commercialize this idea, but it is definitely percolating within the virtual corridors of Brierwood.

The project is a bit like an iceberg in that a large part of the work is hidden beneath the surface on the admin side. There are a lot of people and organizations to keep track of, and all sorts of crazy things happen that need to be recorded.

Fortunately, the folks over at Giraffe Soft have a really nice plugin for exactly this type of thing called timeline_fu. It makes it very easy to create simple events with associated actors and subjects… just go and read the documentation.

For example, we often need to contact organizations and get them to claim a profile on the site that one or more users have selected as a recipient. With timeline_fu, we can declare these events directly in the model file to get triggered when an invitation is created and destroyed.

fires :new_invitation,   n => :create, :actor => :sender,
    :secondary_subject => :recipient_profile
fires :cancel_invitation,   n => :destroy, :actor => :sender,
    :secondary_subject => :recipient_profile

These events can be triggered on new, destroy, and update events. However, one case that is not handled is when there is an event that does not involve any changes to the model object. For example, when we resend an invitation to a user, it is just an email going off. We would like to have something like the following:

fires_manually :resend_invitation, :actor => :sender,
    :secondary_subject => :recipient_profile

We would like to keep the same declaration syntax and everything… nice and DRY. In order to use it, we could call it from the controller as shown below:

AdminMailer.deliver_recipient_reminder(@invitation)
@invitation.fire_resend_invitation

Of course, this is easily accomplished with some typical Rails monkey patching. I hate it just as much as you do, but at least I’m patching a plugin and not, for example, modifying the behaviour of Rails or the Ruby core libraries.

I created a new file called timeline_fu_additions.rb and put it in our lib directory. In config/initializers I placed a file to load our extension:

require 'timeline_fu_additions' 

ActiveRecord::Base.send :include, TimelineFu::Fires

The source for the timeline_fu_additions is shown below. It is a clone of the standard “fires” class method, with a couple minor modifications.

module TimelineFu
  module Fires
    def self.included(klass)
      klass.send(:extend, ClassMethods)
    end 

    module ClassMethods
      def fires_manually(event_type, opts)
        opts[:subject] = :self unless opts.has_key?(:subject)

        method_name = :"fire_#{event_type}"
        define_method(method_name) do
          create_options = [:actor, :subject, :secondary_subject].inject({}) do |memo, sym|
            case opts[sym]
            when :self
              memo[sym] = self
            else
              memo[sym] = send(opts[sym]) if opts[sym]
            end
            memo
          end
          create_options[:event_type] = event_type.to_s

          TimelineEvent.create!(create_options)
        end
      end
    end
  end
end

That’s it. It seems to work great. We’re in the process of rolling it out on our admin interface, so if there are any bugs, I probably haven’t found them yet. I might be motivated to throw this up on github if there is any interest from the peanut gallery.

Its the professional equivalent of talking about the weather, but
since starting our worker cooperative, it triggers a lot more than the
usual light banter. This is how it usually goes:

"So, what are you working on these days?"

"Shawn, Reid, and I started a co-op."

"A co-op? Like MEC?"

"Well its a workers co-op, so instead of customers being the
shareholders, the employees are. Every employee is an equal owner." I
say.

"So if you hire someone, they become an equal owner?"

"Well, there is a probation period, but yes, they become an equal
owner."

"But..", they hesitate, "how does that work?"

"How does that work?", is code for:

• "How do you maintain control of your company?"
• "How will you ever make decisions without a head honcho?"
• "How will you become rich?"
• "You are crazy!"

These questions are borne from an assumption that the founders of tech
start-ups start with some sort of great idea, then hire some people to
help them turn this winning idea into cash. In that picture, the idea
is the real value, and the obvious difference between the employees
and the owners, is that the owners had the idea.

But, the truth is that ideas are a dime a dozen, and the original idea
is always wrong in some critical way that is only obvious in
hindsight. No tech start-up succeeds following the original plan.

The real value is in vision and execution. In other words, the value is in the
team. And a successful team is made from excellent individuals with a
clear shared vision.

Every company says that "our employees are our strength" or some
equivalent platitude, and it’s really true whether they believe it or
not.

So the answer to the questions about control and decision making is
not that it doesn’t apply to co-ops, but that corporations have the
exact same issues, except they don’t see them. As the major
shareholder of a company, I can force it to take whatever actions I
want. But, if I don’t have buy-in from the team, all those initiatives
will fail and take the vitality of the company with it.
So, sure, I can force the company down some path, but then
I destroy the company. What kind of a choice is that? Who is really in
control?

Control of a tech company boils down to shared
vision. That’s true whether its a co-op or a large corporation with a
majority shareholder. However, in a co-op, the issue is in plain sight
where it has to be dealt with.

So, as the founders of a co-op, how do we control our company?
We don’t. But that was never an
option. All we can do is collaborate to build a vision, and execute on
that.

But vision is only half the equation, you still need excellent
individuals, and that’s where a worker co-op has a clear advantage. We
offer real ownership, all they can offer is a salary and a 5-year
pin.

Even compared to starting your own company, co-ops look pretty good:

• pooled risk.
• co-owners to ride out the ups and downs.
• spend much less time on the petty details of day-to-day operation.
• working in a small team of people who care as much as you do.

And when your done, you can cash-out and graduate on to something else.

We can attract the people who are considering leaving their lucrative
big-company job to start their own company, or the people who have
already made the leap, but are tired of doing it on their own. These
people represent the cream-of-the-crop in this field. With people like
that on board, we can’t help but succeed.

Which brings us finally to money. The major objection to becoming a
co-op is you lose your opportunity to really cash-in if you are
successful. The key is: "if". Would you rather $1000 for sure, or a
1/10 shot at $2000?

If you get a team of talented individuals with vision, there will be
money enough to go around. If you try to do it with whatever team you can
scrape together cheap, you can keep most of it yourself, but it
will take a lot of luck to make anything at all.

As Shawn pointed out in a previous post, the barrier to entry is low, and the value is in the labour.

In other words, the talented
people don’t need your job any more, and they aren’t going to settle
for a small slice of the pie.

The landscape of tech companies is changing. I think that we are ahead
of the curve, it won’t be long before the advantages of co-ops become
widely understood. Soon, when you tell people you started a co-op,
they will say, "like Brierwood?"

By far the most controversial part of the article is calling this New Socialism. It seems to me that the word socialism is a pejorative, especially in the United States, where most of the discussion about socialism seems to be carried out by people who don’t know what it is. Even the article’s description of “Old Socialism” seems quite strange to me, not really resembling the socialism I grew up under. But I suppose that the term is broad and vague, and socialism itself has taken on many forms around the world.

What the author is basically talking about, however, is the marriage of the cooperative movement, and more specifically the worker coop movement, with the enabling technologies of the internet. Oddly, this is called collectivism in the article and the term cooperation is relegated to collaboration, the level below. This movement has a fairly long history, including Leland Stanford if you believe this article (there’s nothing at all about it on wikipedia, so I’m in need of clarification here), and most notably the Mondragon corporation in Spain. I really believe that the advanced communication technologies we have now make this vision of peer-production more realistic and practical than it ever was in the past. Simple, peer-to-peer tools to aid in consensus-making and the sharing and distribution of information means that a workplace that is much more radically democratic and autonomous is now possible.

We took the following view in founding Brierwood Design: with products like Amazon EC2, the capital costs of entering the marketplace are almost nil. Value is created by combining highly skilled labor with a small amount of capital (such as my laptop and an internet connection). Therefore, it is the labor investment that is the most important factor to the company, and so it is that investment that takes the risk (I’ll explain how another time) and should be poised to reap the rewards. So in our case, we decided that the control and largest upside would not rest with investors, or with founders, but with the people taking the risk and creating the value — the employees. And this is the logic that led us to becoming a worker cooperative, and in my opinion is very much in the spirit of modern creations such as Wikipedia, Creative Commons, etc.

So, is it right to call this New Socialism? Maybe, although the term is probably too loaded to mean anything anymore. If you think that socialism means control of industry by the state, then it definitely isn’t. On the other hand, if you see the intent of socialism as putting control of industry in the hands of individual producers, then it most certainly is.

I’ve been fortunate to be back working with one my favourite langugages—- Python. However, things have changed with Python since I was in my py-programming peak; both in terms of language features and some of the standard libraries. I’m also happy to add that all of the changes seem to be for the better.

My starting point was a mySQL database. I extracted the data using a simple mysqldump with the XML feature turned on:

$ mysqldump -X ---user=<db_user> --password <database_name> > dump.xml

The result was a massive XML file. That is actually a remarkable side-note. Emacs warned me about loading a file this large, and took a bit of time to bring it up, but afterwards, it was incredibly responsive and searchable. I wouldn’t even attempt something like this with my other favourite editor Textmate.

A typical record from the database looks something like this:

  <table_data name="user">
    <row>
      <field name="user_id">59</field>
      <field name="user_name">Kent Barber</field>
      <field name="user_username">shamal</field>
    </row>
  </table_data>

The last time I did XML processing in Python, things were very different. I tended to simple SAX-based parsers back then. Nowadays, there are fancy alternative like ElementTree which make many things easier.

My end goal was to be able to write simple little functions which know how to construct the objects in my shiny new Django database:

@with_rows_from("user")
def process_user(fields):
  u = User(name=fields['user_name'], username=fields['user_username'])
  u.save()

To accomplish this, I wrote a little decorator class that takes the name of a table from the database, collects all of the fields, and then calls the decorated function. I know there are other ways to accomplish this same thing that are arguably better, but I really like decorators. I like the way they make the code look and read.

class with_rows_from(object):
  def __init__(self, table_name):
    self.table = table_name

  def __call__(self, fn):
    def wrapped(records):
      for data in records.findall("//database/table_data"):
        if data.get('name') == self.table:
          for row in data.findall(".//row"):
            fields = {}
            for f in row.findall(".//field"):
              fields[f.get('name')] = f.text
            fn(fields)

    return wrapped

At the top-level, I can extract all the user objects with something like this:

from xml.etree import ElementTree as ET
records = ET.parse('dump.xml')
process_user(records)

I love this language. Now, back to my migration. There are obviously some other complications that I’ll have to deal with, but maybe that will be another post.