It is difficult to practice collaboration while always moving forward. A team of people together, have different ideas on timelines, objectives, leadership, and engineering. The competition complicates getting something completed.
Can we agree to get a group of interested people together to decide on issues on a repeating schedule? We likely will need to have two groups, one technical and one non-technical. Each group needs responsibilities and objectives. There should be little to no overlap between the two groups. The non-technical group should not be telling the technical group how long their development cycles are, but they can establish high level objectives for the technical group to meet.
Can we agree on what we are building, why it is being built, and who it is being built for? The responsibility of a Product Owner or Manager must be filled by someone, even if that role is not formally defined. These basics must be settled and broken down by priorities, then the project can move forward. Failure is certain if the customer’s needs for a product are not enshrined in the project that is doing the work.
Stupid ideas are a fact of life. We make mistakes. Say dumb things. The ability to learn and grow from stupidity and failure is critical. I can easily point out what I did wrong last year, when I was at Yahoo, when I was managing storage arrays. I am always taking in my mistakes, especially my stupid ones, and applying what I learned from it to my next decision. Projects that do not adapt quickly to failure and stupid mistakes fail every time. Collaboration in an effective team is constantly learning and adjusting while still focused on the product. Every time I have been part of an organization that was slow to learn from mistakes, we were unsuccessful.
The practice of working in a public way, exposing ideas and objectives in the open, can be used by anyone. The true benefit of open source software development is not the code. The true benefit of open source is the practice of working together in the open during project development. Developing ideas and collaborating on product ideas and what the customer needs during and around the software pipeline. Allowing many engineers and developers to review code submissions and tests in the pipeline before the code is merged. The ability propose new approach alongside everyone’s work. These are the gifts of open source that we need to practice to improve working together.
