How Not To Run An Opensource Project

Photo by Markus Winkler

A lot happened before … but everything fell into place ~ Hiroshi Oshima

About

Walter gives us an insight of how his opensource project with over 5000 stars became a failure.

By walter Schulze - writer of gogo protobuf

Discussions on the project

Strategies for failing at opensource

• Don’t opensource
• Solve a problem that does not exist
• Soft fork:
• Use analogies
• Nitpick and become hostile:- nitpicing is not picking the right battles
• Create a logo using paint
• Using Google+ to market your stuff
• Find out where the community hangs out and uninstall the application: (you should adjust on how people want to communicate rather than how you want to communicate)
• Allow too much customization
• Be the sole maintainer
• Attach meaning to github stars - no correlation between stars and users
• See open source as your CV
• A haircut is as good as a holiday - (a change is as good as a holiday) - take vacations from coding
• Be too shy to do any talks.
• Get carried away with features - Adding features nobody asked for
• Leave the company that paid you to work on opensource
• When you leave, take the opensource project burden with you
• Add features no user requested
• Give 110% to opensource
• Add projects no user requested
• Make another soft fork
• Refuse to involve others who want to help
• Find a bunch of new interests
• Burnout
• Don’t set healthy boundaries
• Attach your self-worth to opensource
• Never plan for succession
• Don’t write tests
• Have no CI - YOLO
• Let new maintainers get started witha Massive change
• Have no consensus mechanism
• Don’t have any time at work dedicated to an opensource project that needs support, and is used by the same company where you are working
• Decision paralysis
• Inevitable burnout

📺 Youtube ref