Hacker News Post re: Co-op Consultancy

[kahunamoore]

All,

There is an interesting discussion over on HN re: software consultacies, see:

https://news.ycombinator.com/item?id=9080630

It is good to see someone else thinking about Co-ops and software - there really is a building sentiment in the OSS community re: the taker-mentality so there might be some additional motivation to adopt these principles.

I'm off to re-read the article and will comment further shortly.

Alan

[kahunamoore]

Some comments from the essay:

• trust networks over rating systems
  
• equitable distribution over price competition
  
• design iteration over spec writing
  
• ownership over quality control
  

These are great points, especially considering the "consultancy" focus. Clearly the market they are talking about is similar to markets I would consider important for targeting.

Lets take these one at a time:

Trust Networks vs. rating systems

I often vacillate on the trust networks vs rating systems aspect. While I believe hiring is critical I also think there is value in finding people who want to work on the problems that you are solving - but how likely is it that you already know the best person. Maybe they live in Canada... and while number of degrees of separation between you and that person might be small it can be difficult to traverse or discover. Maybe you need to find the right person and *then* determine how you might know them... sounds like a fun graph traversal problem to me!

My experience in the OSS world tells me that often people self-select around problems they want to solve - so maybe, in that world, people already know each other. But the friction encountered in getting organized into a legal entity and the nature of Open Source licenses make it hard to leverage the technology without facing competition from free-riders. Hence the Freemium model around web-based services... but even that doesn't scale nor appeal to the firms in the target markets identified in the article.

My current thinking is that it is better to open Co-op Source to anyone who wants to join as opposed to filtering or only inviting my extensive personal network of Silicon Valley veterans. For the opportunity in front of us now, Co-op Source needs to scale in order to fulfill my long term goals for it.

Co-op Source needs scale to allow us to solve really hard problems in a number of domains. We need scale to allow us to re-think a lot of assumptions in software development that originated from a competition-centric world view. I have been studying economics in order to help me better understand the consequences of the various approaches. I believe we need to start small and build up the resources that will allow us to "quit the day job" and start working towards a future that we own together.

Equitable Distribution over Price Competition

I totally agree on this point. I think making the "equitable distribution" as simple as possible to reduce friction is very very important. In his excellent book "Slicing Pie" Mike Moyer advocates (1) using a dynamic equity split that is based on "allocating equity based on the relative, theoretical value of the ingredients at any given time." (1) I posted about this book previously and will probably re-read those sections for further insight. I highly recommend it.

Design Iteration over Spec Writing

The author is presumably talking about RFPs and similar sales/contract cycles vs more agile methods where the client is simply paying by the hour. At least that was my understanding.

In the Co-op Source model, I see having the client being part of the cooperative. What that actually looks like I'm not sure but it opens up the possibility of using crowd/funding and/or client/financing for projects *within* the membership (not open to the general public) but there are legal aspects to this that require further investigation.

Different problems in software engineering lend themselves to the agile approach but I think some problems will require a more formal, yet iterative, design process. How this plays out in the Co-op Source context is still an open question.

Ownership over Quality Control

What I take from this is that if you have ownership of your work product that you will ensure quality from the outset. Your motivations are different when you have agency in the code itself - you are not just cranking out code for a client.

This is one area where the terms of the Co-op Source license can align the interests of both the developer, and all other cooperative members, and the client. Providing the source code to the client gives them the freedom to fix their own problems or hack the code for their own purposes (but not for re-sale or otherwise compete with the cooperative.)

The terms also state that the cooperative (developers) retain the rights to the code on an ongoing basis and any improvements or fixes they add. The clients are incentivized to work with the cooperative developers to improve the product and the developers are incentivized to meet the client's evolving needs.

Software is a perishable good - it must be maintained or code rot sets in. One consequence of this is that the value of the source code actually lies with the developers who understand it. Most non-trivial software, e.g. code that solves hard problems, will require dedicated resources. Given that cooperatives are one of the most stable enterprises, risk is minimized when using products built by Co-op Source projects.

This is just my current thinking on these subjects and it is subject to revision as I learn and think things through as I have been doing for quite some time! As the saying goes "Strong opinions, weakly held"... actually, in my case, these are strong principles, strongly held. The details or approaches may change but the intent is clear. Fairness and transparency rules!

Did you read the article and if so what are your thoughts on it?

Alan

1) Moyer, Mike (2012-09-04). Slicing Pie: Fund Your Company Without Funds (p. 47). Lake Shark Ventures, LLC. Kindle Edition. 

[Bill Glover]

I read the article and it sounded like a bold start. I don't think they have things figured out yet, but they seem game to try. I think that's a big part of success with something like this. Starting early and getting alot of feedback.

On trust networks vs. rating. Both have their failings and both can be gamed, but I think trust networks are less artificial and we have more social systems for monitoring and maintaining them. Just my two bits.

--
You received this message because you are subscribed to the Google Groups "Co-op Source" group.
To unsubscribe from this group and stop receiving emails from it, send an email to coopsource+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alan Moore]

I thought I replied to this already... maybe I never pressed Post.

inline...

On Sunday, February 22, 2015 at 12:35:57 AM UTC-8, Bill Glover wrote:

I read the article and it sounded like a bold start. I don't think they have things figured out yet, but they seem game to try. I think that's a big part of success with something like this. Starting early and getting alot of feedback.

Yes, we are starting about as early as you can get - haven't nailed down a bunch of variables. Sometimes choosing is the hardest part, especially when many of the options seem like they would work.

 

On trust networks vs. rating. Both have their failings and both can be gamed, but I think trust networks are less artificial and we have more social systems for monitoring and maintaining them. Just my two bits.

I like trust networks more but something tells me scaling is important so it is tempting to rely on rating systems. I think with a self selecting group the likely hood that trust networks can become established within the membership are high.

I still need to think this through further. Thanks for your insight.

Alan

 

To unsubscribe from this group and stop receiving emails from it, send an email to coopsource+unsubscribe@googlegroups.com.