Huh? A Software Cooperative?

I recently wrote about how thankful I am, after a decade in software, to work for an employer which inherently understands my values and the values of all my colleagues. That employer is me. That employer is also all of my colleagues. That employer is nilenso: a software cooperative owned and operated by its employees here in Bangalore.


What is a coop?

According to Wikipedia: “A cooperative (“coop”) or co-operative (“co-op”) is an autonomous association of persons who voluntarily cooperate for their mutual social, economic, and cultural benefit.”

That’s a bit vague. This higher-level description of cooperatives includes things like housing cooperatives, social cooperatives (employing the previously unemployable), and consumers’ cooperatives (owned by its customers). I won’t be discussing cooperatives of this structure, but a housing cooperative is a helpful illustration:





Let’s use this cute, orange condo building as a conversation piece. Normally when we think of condominiums we think of the green building: it’s entirely owned by a property developer (see the helpful pie chart?). Each condo is sold to an individual and that individual has no ownership or authority over the building as a whole. It’s possible for the owner of an individual condo to join the condo board to deal with issues like the noisy neighbour who comes home at 3:00 AM to listen to Taylor Swift remixes. It’s not possible for the condo board to prevent that noisy person from purchasing a condo unit in the first place.

The yellow building presents the alternative: each condo owner not only owns their own unit, but also a percentage of the building itself (usually 1/N, where N is the number of condo unit owners). The building is still owned by a corporation. But now, rather than some external entity, the corporation which owns the building is itself owned by the residents of the building. Here, your pink penthouse also gives you a pink slice of the overall pie.

For the purposes of our discussion, the cooperatives we’re discussing are profit-seeking corporations  participants of the market economy. Let’s use nilenso as a canonical example. Nilenso operates externally as any other business would: an employee in an executive capacity sign contracts with our clients, the company mails out invoices for work we’ve completed, the company pays rent for office space, the company collects profits. Yadda, yadda.

Internally, however, things are slightly different. Rather than “founders” owning and operating the business however they like, nilenso is owned equally by every employee and operated by an elected Executive. Our salary structure is completely transparent. As are our books. As are all of our business conversations. Large decisions (like hiring a new member – or firing someone, if it ever came to it) require a two-thirds majority. Since everyone in the company is an owner, everyone also has agency. Want a new keyboard? Need a book? Headphones? Office furniture? Grab the company credit card and execute; there’s no one here to babysit you.

To make use of more ridiculous pie charts, ownership in nilenso (and therefore, votes) looks like this:




The usual idea of fun, young businesses run as employee-owned cooperatives probably conjures up images of this guy and his life partner, running their organic, fair-trade, non-GMO coffee roasterie and espresso shop:



That guy looks like a he’d run a solid coffee shop. Or… lumberyard. But he probably won’t grow that into a multinational corporation any day soon. Many people don’t realize that big coops do exist. Larger cooperatives (like the unimaginatively-named Federated Cooperatives Ltd. of my home country) adjust their structure to handle scale: with thousands of employees, they will have a board in addition to an elected executive. They will have departments and budgets and middle managers. They will look much more like a regular corporation internally than little 12-person nilenso does. But they are still owned and operated by their employees and they are still very much cooperatives. There’s nothing about a cooperative which prevents it from being pedestrian.


Why build a cooperative?

Why do we prefer to live in a democracy? We prefer a society in which governance is not military, not centralized, and not dictatorial. We prefer to have the power to fire a government (and government agents) if they aren’t acting in the citizens’ best interests. Well, a corporation is always governed by someone, and in a cooperative that someone is you. A cooperative is a democracy.

This capitalist democracy is not all that different from the democracy of a nationstate. An executive body is elected and maintains tenure for a predetermined period until the next election is held. Large decisions can be put to a referendum. In both cases, citizens (employees) have agency.

This also lends itself to transparency. A business led by uninformed decisions is a business doomed to fail. If the most important decisions of the business are left to the employees, the employees must have full access to information about its operation: How are salaries structured? Bonuses? What is our P&L? Who is authorizing expenses? Who is responsible for what income? Who is exceeding expectations? How?

From transparency come checks and balances. It’s easy to see how an opaque, privately-owned company like Koch Industries could run so far astray of meaningful, productive, progressive business as it has. But even publicly-held companies lack serious checks and balances. Bear Stearns, Lehman Brothers, and General Motors are public financial failures. Public companies are also subject to environmental disaster, contribution to war, human rights abuses, and corruption of politics. Most people don’t think of Apple or British Petroleum as inherently flawed or evil. And perhaps they aren’t, yet. But when corporate checks and balances are comprised of profit motives alone, it’s not impossible to imagine public companies becoming meaningless, unproductive, and retrograde societal scars, like Koch.

Transparency and a self-regulating system won’t be perfect, of course. Cooperative oil companies still have refinery explosions and oil spills. An employee-owned company distributes the greed of an individual “founder” to its entire staff, rather than eliminating it. But it would take formidable collective greed for a cooperative to brush off environmental & safety issues, buy politicians, or hire an international contractor known for its human rights abuses. On the other end of the scale, the agency provided to members of a cooperative make “corporate social responsibility” a daily activity, rather than an afterthought. At nilenso, we think collectively about our office waste, how we treat our contractors, and how we interact with our local community.

Perhaps, as a software developer, you don’t care about the environment. Maybe you don’t care about the company’s financials or the sales cycle or improving the local community. Cool. You are perfect for a cooperative. What do you care about? Good coffee? A parking space? A gym membership? Software licenses? Conferences? Coops have you covered. Join, speak up, and change the company into what you want it to be. Remember: a coop is your company, in the most literal sense. Technology companies love to proclaim “this is your company”, “we want you to be your own boss”, and “we want entrepreneurs”. But this is all hand-waving unless it means something legally.


Challenges

If running a cooperative interests you, I’d like to provide fair warning that starting and running a cooperative is not without its own set of difficulties. At nilenso, it took us months to figure out our executive structure. Prior to that, we held a lot of referendums and decisions were made slowly. Finding a structure that works for you will take time.

A “Cooperative Corporation” is a specific legal entity, and nilenso isn’t an internationally recognized Cooperative Corporation. India’s Cooperative laws are antiquated, to say the least. Most of the cooperatives in India are either agriculture firms or small banks, and most of the laws are targeted at agri-business. A generic Cooperative Corporation in India requires a minimum of 50 (or 60, depending on which government document you read) employees and cannot own an international subsidiary. That’s a big ball of nonstarter for us.

Your country might have similar restrictions  or you might just prefer the flexibility of starting a cooperative under another category of legal entities. Our lawyer recommended we use an LLP (Limited Liability Partnership), so our first partnership agreement looked like this:




This works well enough. The LLP can own international subsidiaries (like our California-based C-Corp), can contain any number of employees-as-partners, and we can write up the partnership agreement to reflect the structure we want for the corporation. With every person who joins or leaves nilenso, we rewrite the partnership agreement to add or remove them.

While everyone in nilenso owns (1/N)% of the company, we strive to make it a meritocracy: we have salary bands and everyone is slotted into a salary band based on her/his skills, experience, and contributions to the company. The partnership agreement doesn’t affect anyone’s finances, since all remuneration is through the salary structure.

Uncommon is the only other software cooperative in India that I’m aware of. They’ve taken another, totally valid strategy: They are structured as a Private Limited corporation. Rather than partners, every employee of Uncommon is a director and rather than a static salary structure, every employee takes home a salary corresponding to the work they’ve delivered that month.

Hiring and firing is one of the most difficult aspects of running any business, but it’s even more difficult with a cooperative structured as a partnership. Decide procedures for employee on-boarding and exits before you start  then write them down. It’s tempting to believe a team of friends will always be as happy and cohesive as they were on Day One… but it’s a delusion. You are running a business and it’s going to grow or fail. Either way, be ready.

Last but not least, a coop can’t receive venture capital since that would mean the company was no longer owned by its employees. There are ways around this through child companies, joint ventures, and the like. But for someone like me who’s not keen on the VC scene anyway, it’s not really an issue. For us, this meant having enough cash in the bank to get nilenso off the ground in the first place.


What is nilenso?

Over the past year, the twelve of us have decided what nilenso is: Our primary focus is building increasingly sophisticated software. This past year, we’ve made wonderful tools of devops automation, distributed computing, machine learning, and multi-variate testing. Our tools and skills will only get more interesting and what defines “interesting” is decided by us! As a group, our office is excited about using this toolset, particularly through open source, to enhance essential services: water, food, housing, healthcare, education, scientific exploration.

But what we’re excited about goes beyond software. We’ve made the nilenso office a space where we want to be: We have a library packed with books and meditation cushions. We have a washing machine. We have a nap room. We get healthy, homemade food catered for lunch in environmentally-friendly tiffins. We are investing in the education of our contract staff (cleaning and security). We have a composter for food waste and we recycle everything else. We have secure bicycle and car parking. We have delicious South Indian coffee. Over the next year, we’ll change this so that nilenso is the kind of company we want in 2016.

That all describes what nilenso looks like more than it describes what nilenso actually is. Nilenso started as an experiment. None of us were sure if a software cooperative made sense or if we could make it work. After a year and a half, nilenso has grown from an experiment to an idea we want to share. We encourage you to try it out, criticize it, expand on it, and tear it apart. Resilient software systems are made through flexibility and by facing unforeseen obstacles. Resilient businesses are likely to be made of the same stuff.

What would your technology cooperative look like?

Original post by Steven Deobald - check out Hungry, horny, sleepy, curious.

Welcome, Gratitude.


I recently suffered the most severe injuries of my life - I experienced a retinal tear and detachment which led to multiple surgeries. Those surgeries themselves have permanently damaged my vision and physically deformed my right eye. While I was recovering, I was unable to read, use a computer, or watch video. Oh. And I was in California, on business. The surgeries prevented me from flying so I was unable to go home to India or home-home to Canada. When one is confronted with such restrictions, a strategy is required.

The strategy recommended by everyone I spoke to was familiar: distraction. “You can’t read? You should watch movies!” “You can’t even watch TV? You should definitely get some audiobooks.” The familiar imagery of a sick child surrounded by books, video games, and constant television stood in stark contrast to the time I spent trapped in a Marriott. I meditated. I bathed. I ate. I thought.

Thus far, I have been on 4 silent meditation “retreats”. Being entirely alone with one’s self is difficult, even when life feels perfectly balanced and content. To attempt such a “retreat” on my own in the midst of my first medical trauma was to oscillate on an emotional sling. This mental and emotional cha-cha danced over both habit and interpretation. In pondering the latter, I arrived at some conclusions which rang truer the more I pondered them.

Habit and emotion was the first constant struggle I encountered. It took a surprising amount of patience to acknowledge, even for a moment, that the accident leading to my retinal tear was entirely my fault. If I fixated on any of the factors leading up to the surgery, I’d find myself externalizing blame for hours. My reptile brain was furious and anxious to pin the blame on the optometrists who refused to sell me contact lenses, the distractions I had encountered riding home that night, and even my friends.

Acknowledging and accepting that the accident was entirely my fault turned out to be only half the battle. Yes, I had decided to ride a bicycle after drinking with friends, with glasses on, late at night, in the dark. Yes. “I” had made these choices. But who was “I”? Was the me of a month prior so much worse a person than I was in the moment of remembering? Was the me of the past worthy of my anger and disappointment? Day by day, I came to see externalizing blame and time-shifting blame to be quite similar. The past is undeniably immutable and yet we humans seem prone to lament and regret the decisions and experiences which created the immediate world we now live in.

Whenever I became obsessed with externalizing the causes of my feelings, I found the only real emotion I would ever hold on to for an extended period of time was anger. Feeling sad? Find a reason to be angry about the thing that “made me sad”. Feeling anxious? Don’t worry! That emotion is easily stomped on by a good bout of rage. Feeling fear? Humanity has long since proven the best solution to sources of fear are to destroy them. And if we’re powerless to destroy mosquitoes buzzing in our ears, the very least we can do it sit around and hate them passionately. As weeks passed, my eye stopped bleeding and eventually lost its sensitivity to the light so I could go outside. But while trapped inside I was vexed by a world of violence, a temporary home in a country with a savage healthcare system, topical police brutality, an ignorant march of Atheists creating A New Religion, global warming, and -my god!- my hotel room didn’t have recycling!

The other end of the emotional sling was more productive and the sling did reach this productive end on occasion. While trapped alone with my damaged eyeball, anger was most often a thin veil for fear. My Aunt had sent me an email (read to me by a friend, since I couldn’t read it) describing neurological research which placed fear and gratefulness on two ends of an emotional spectrum which could not be tied up simultaneously, thanks to limitations of the human brain. It appeared she was right. While it was easier to fantasize about changing the world into a more beautiful, more scientific, more peaceful place it was not all that difficult to be thankful for the world I was presently experiencing. Similarly, while it was easier to fantasize about having my sight back it was not impossible to be thankful for what sight I still had. With every moment of gratefulness came another. Meditating on gratefulness for a few hours a day, constantly returning to feelings of gratefulness when I was distracted by fear, the moments began to snowball. Soon, full days were spent distancing myself from feelings of fear and anger, even while I was in very intense pain. The distance wasn’t rejecting emotion or burying it, however. It was a genuine disinterest in indulging those hateful fantasies I had in prior days.

What I found interesting about gratitude was that it left me surveying where I was, what I was doing, and how I viewed the exciting opportunities which lay ahead. Where anger became narrowing and obsessive, gratitude appeared to grow boundlessly and open new doors to thought and creativity as it went. I had shifted my focus from emotion to interpretation.

I began to ponder my ideals, my philosophy, and my “spirituality” (for lack of a better term). Having recently watched Carl Sagan’s original “Cosmos” series, the notion of the Cosmic Calendar, in which the existence of the universe spans one calendar year and the existence of homo sapiens sapiens spans eight full minutes, I began to linger on the idea of human progress viewed under a 200,000 year lens. Previous visualizations of the scientifically observable universe (such as scaleofuniverse.com) always left me feeling utterly insignificant, as though the time scale of the universe were so large as to exist beyond comprehension. The scale of the Cosmic Calendar was comfortingly familiar: I had experienced one year and knew what it felt like. I had experienced milliseconds and knew what they felt like. The scale presented me with a foundation for the consideration of my own actions which did not reduce me (and everyone else) to the infinitesimally small.

I’ve spent much of my life in search of moments where I felt relevant: scoring a goal, making someone laugh, getting a raise, making a new friend, convincing others of my opinions, demonstrating my intelligence or strength or stamina. Structured as events, every success is ephemeral. Structured as events, my relevance is fleeting. Structured as participating in a continuum, my relevance is not only constant but does not require my superiority over another person in any way. While exploring this idea, it became apparent that the difference between perceived relevance as an aggregation of events and perceived relevance as participation in a continuum was the role of the individual, the self. In the former case, individualism mirrors my fears. The goals and accomplishments of the past are increasingly narrowing of what defines success in the future; my next accomplishment must outstrip my last. In the latter case, individualism is a paradox and mirrors the joy and gratefulness attached to the opposing end of the emotional spectrum. On a 100,000-year timescale, our efforts are collective, cooperative and our “selves” are limitations of perception provided for us to overcome. Within this paradox, the limitations of my “self” are yet one more thing to be grateful for: I get to overcome my self-perception. While held in these moments of intense gratitude, self-reflection could be identified in no other way. On a superficial level, where in the past I’ve believed myself to observe argument objectively, such joy found in the concept of self-destruction appears nihilistic. I am convinced it is not but to state otherwise without evidence is to ask the reader to indulge in faith or to admit defeat in my ability to dissect what I’ve observed. Without taking either of those two roads, I hope to unravel that paradox in future essays.

“Where am I? What am I doing?” is a common reflective question for anyone, but particularly for women and men who work in technology. We love to change jobs every year or three, and in my experience a grass-is-always-greener (giag) approach rarely fails. The grass often is greener. Persistent gratefulness changes the answer to this question, though. Where giag says “jump ship!”, gratitude says “try steering this ship first.”

As a partner of an employee-owned technology cooperative, I get to help steer the ship. I can see that the experiments we run and the conclusions we draw directly influence our collective understanding of what we are building together. Everything we build together lives on a continuum of progress: the entirety of our business, a significant part of our individual lives, and a tiny (but not inconsequential) part of humanity. As I found in quiet moments alone in a darkened room of a Marriott, the consequence of gratitude is to find another source of gratitude. I am very fortunate to be where I am and I’m increasingly thankful for the opportunity to see what’s next.
Original post by Steven Deobald - check out Hungry, horny, sleepy, curious.

Functional Programming 101 - With Haskell

In this blog post, I'll attempt to explain some basic concepts of Functional Programming, using Haskell. This blog post isn't about Haskell per-se, but about one way of approaching this problem, which demonstrates the benefits of functional programming.

You can run most of these examples in ghci, by saving the contents of the example into a .hs file, loading up ghci and running :load file.hs.

Many thanks to Mattox Beckman for coming up with the programming exercise, and Junjie Ying for coming finding a better data structure for this explanation than I came up with.

The Problem

You are Hercules, about to fight the dreaded Hydra. The Hydra has 9 heads. When a head is chopped off, it spawns 8 more heads. When one of these 8 heads is cut off, each one spawns out 7 more heads. Chopping one of these spawns 6 more heads, and so on until the weakest head of the hydra will not spawn out any more heads.

Our job is to figure out how many chops Hercules needs to make in order to kill all heads of the Hydra. And no, it's not n!.

Prelude: Simple Overview Of Haskell Syntax

Before we dive into code, i'll explain a few constructs which are unique to Haskell, so it's easy for non Haskellers.

  • List Creation: You can create a list / array using the : operator. This can even be done lazily to get an infinite list.
  • Defining Function: Looks just like defining a variable, but it takes parameters. One way they are different from other languages is the ability to do pattern matching to simplify your code. Here, I define a method that sums all the elements of a list.
  • More List Foo: Adding lists can be done with ++. Checking if a list is empty can be done with null. You can use replicate to create a list with the same elements over and over.

Choosing a data structure

Let's choose a simple data structure to represent the hydra. We'll pick an array to represent the heads of the Hydra, using the level of each head as the value. The initial state of the Hydra (with 9 level 9 heads) can be represented as follows: [9, 9, 9, 9, 9, 9, 9, 9, 9].

Chopping off a head

The whole point of functional programming is to build small functions and compose them later. We'll build a few functions, specific to our domain, and a few more general ones to orchestrate.

Let's first build a specific function to chop off the Hydra's head. We know that chopping off one level 9 head should result in 8 level 8 heads (and 8 of the original level 9 heads). This is represented as [8, 8, 8, 8, 8, 8, 8, 8, 9, 9, 9, 9, 9, 9, 9, 9]

Let's build the chop function. It takes a single argument, and the current levels of the all live heads. It will return the state of the heads after chopping the first one.

The three lines of code below map to these rules:

  • If there are no heads left, just return []
  • If we find that there is a level 1 head at the start of our list, just chop it off and return the rest of the array
  • If we find that there is a higher level head at the start of our list, spawn n – 1 heads in it's place

chop []       = []
chop (1:xs) = xs
chop (n:xs) = (replicate (n – 1) (n – 1)) ++ xs
——————————————————————————
chop [1]
— []
chop [4]
— [3, 3, 3]
chop [3, 3, 3]
— [2, 2, 3, 3]
chop [9,9,9,9,9,9,9,9,9]
— [8,8,8,8,8,8,8,8,9,9,9,9,9,9,9,9]

Repeatedly chopping heads

Our function chop is a pure function as, given some input, it always returns the same output, without any sort of side effects. Side effects is a general term for modifying inputs / IO Operations / DB Calls, and so on.

Since chop is pure function, we can safely call it over and over. Let's build a list where each element is the result of chopping the previous element.

repeatedlyChop heads = heads:repeatedlyChop (chop heads)
—————————————————————————————
repeatedlyChop [3]
— [[3],[2,2],[1,2],[2],[1], [], [], [] …]
— this is an infinite list

This paradigm is so common, that we have a functional construct that does this: iterate. We can replace the above code with the following:

repeatedlyChop heads = iterate chop heads

Truncate that infinite list

Great, we now have built a list of all the states the Hydra is in while Hercules is busy chopping away at it. However, this list goes on forever (we never put in a termination condition in the earlier code), so let's do that now.

We can use a simple empty check (null) to test if the hydra is still alive. Let's keep items as long as the Hydra is alive

takeWhileAlive (x:xs) = if null x then [] else x:(takeWhileAlive xs)

Putting the two together

repeatedlyChopTillDead heads = takeWhileAlive (repeatedlyChopTillDead heads)
——————————————————————————————————————
repeatedlyChopTillDead [4]
— [[4],[3,3,3],[2,2,3,3],[1,2,3,3],[2,3,3],[1,3,3],[3,3],[2,2,3],[1,2,3],[2,3],[1,3],[3],[2,2],[1,2],[2],[1]]

Again, these patterns are so common, that we can replace the entire thing with a single line. takeWhile keeps things in the list until the first element that doesn't match.

repeatedlyChopTillDead heads = takeWhile (not.null) (iterate chop heads)

Finishing up

Now that we have the sequence of chops needed to kill that Hydra, figuring out the number of chops is just a matter of figuring out how long the sequence is.

countOfChops heads = length (repeatedlyChopTillDead heads)
—————————————————————————
countOfChops [1] — 1
countOfChops [3] — 5
countOfChops [9,9,9,9,9,9,9,9,9] — 986409 (this takes a while)

Extending

Now that we've solved the problem, what next? How easy is it to extend this? Let's add a new requirement: Hercules, though a half god, can only fight at most n Hydra heads at a time. If the number of Hydra heads goes above n, then hercules dies. Let's make a function willHerculesDie which takes two parameters, n and the Hydra.

Turns out, this is pretty simple. We just need to count all the heads that are alive. If the count is more than n at any point, then we return true, and Hercules dies.

willHerculesDie n heads = any (> n) (map length (repeatedlyChopTillDead heads))
——————————————————————————————————————
willHerculesDie 37 [9,9,9,9,9,9,9,9,9] — False
willHerculesDie 36 [9,9,9,9,9,9,9,9,9] — True

So what next?

We've built a bunch of really composable functions, and we can look at each one independently to tune the system.

You can get Haskell set up with the Haskell Platform and play around with the code here.

Some great books you can check out:


If you liked this post, you could:

upvote it on Hacker News

<i>Original post by <a href="http://twitter.com/tdinkar">Tejas Dinkar</a> - check out <a href="http://blog.gja.in/">Side Effect Free Rants</a></i>