Analysis of dat community culture and development approach

[aschrijver]

(NOTE This proposal is part 1a of Positioning, vision and future direction of the Dat Project)

As a newcomer to dat coming from a business-oriented development culture I made some interesting observations on the dat community culture that I would like to analyse further. (Note: This discussion was started in sciencefair-land/sciencefair#153)

PS I admire all the great people I've met so far! Below analysis is only meant to be constructive, and in no way offensive.

Community culture swot analysis

Strengths:

• open-minded to technology and new ideas
• creative, innovative
• very hands-on, practical
• proficient, much expertise present
• slightly anarchistic
• strong ethics, morals
• informal, self-organizing

Weaknesses:

• missing (or well-hidden) strategic focus
• fragmented, too disorganized
• inward-focussed, opaque to newcomers
• reliance on individuals
• implicit programmer anarchy
• little attention to community building

Opportunities:

• follow clear community engagement strategy
• activate the community, and save yourself time
• reposition for greater reach, without the drawbacks
• nurture an appropriate, goal-oriented community mindset

Threats:

• developer myopia
• religious superstitions (e.g. wrt 'node vs jvm')
• un-preparedness for traction
• long-term success formula not clear

---

reliance on individuals

Consider if one core team member - e.g. @mafintosh - is suddenly no longer available to the dat project or at all, e.g. due to other cool job, sabbatical, or personal reasons?

• What happens to his 650 personal repositories and numerous other ones? Who will maintain them? Can you take over, or do you have to fork?
• Is there enough expertise with the remaining team on encryption, streams, networking, etc. to keep the dat project going?
• If not, how easy can you find someone that can replace him, especially if the community is still relatively small?

implicit programmer anarchy

The community culture swot traits above are reflected in the general approach to development, which I would describe as implicit programmer anarchy (as opposed to explicitly opting for this approach).

From What is programmer anarchy and does it have a future?:

[So] Programmer Anarchy is…

• At the start of the day the programmers choose their own work during daily stand-up meetings
• There are no PMs, Iteration Managers, BAs, QAs / testers or “managers of programmers” – all the normal rules of managing software development in a professional environment are gone. This is on the basis that formality and rules are constraining to creativity and productivity
• It runs on the concept that with no managers to give power to their programmers to go ahead and develop (managers “empowering” their teams), programmers go ahead and take total responsibility for the success of each project in a form of self-organised “anarchy”
• Integral to this is the adoption of the mindset “what if you were guaranteed not to fail” and the idea that disagreement and failure is expected, and both are ultimately productive outcomes. They want programmers to lose the “fear of failure”
• Programmers work directly with the customer, which builds more trust and understanding about how the SDLC is affecting delivery
• And to top it off Programmer Anarchy is still Agile Manifesto compliant:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

But: Not explicitly recognized, chosen or followed. The anarchism follows from cultural traits

developer myopia antipattern

There may already be some 'developer myopia' at play in dat project. A risk that is likely to increase if not tackled.

When you're deep in a project it's hard to relate to people seeing it for the first time.

This antipattern is very similar to 'marketing myopia':

The Myopic cultures, Levitt postulated, would pave the way for a business to fail, due to the short-sighted mindset and illusion that a firm is in a so-called 'growth industry'. This belief leads to complacency and a loss of sight of what customers want.

Taking a step back regularly and reconsider what you're doing and where you're headed is sensible advice, and boils down to becoming a bit more strategic in your approach.

---

Next part: Improve dat-awesome page

[aschrijver]

PS This excellent TechBeacon article has many nice culture improvement ideas: Lessons from 7 highly successful software engineering cultures

[aschrijver]

You're welcome @Vedikaledange
I haven't checked Dat for a while, so much may have changed. For example, datproject.org website has been revamped and improved since, and there are other organizational changes.