Linux is NOT a text editor!

Also, they want to Richard Simmons videos. I caught them doing it. I was disgusted. I put in a Jessica Biel video, but they started to cry.

Firstly, developers started feeling pushed. Part of this was the Director aspect: setting deadlines, following up with devs on % completion, etc. Being hobbyists, the developers generally tried to avoid all questions of ETA, or responded with an ETA that could please this director only to attempt to postpone it later (having to deal with extra pressure because they had already promised a feature). Well, this is off-topic though. This is not on the Project Management side of this.

On Project Management it was actually worse!!! In the beginning, his role was welcomed. It seemed that he really checked what users wanted in general, weighted and prioritized tickets, streamlined communication and development, etc. However, soon enough it all came down to “the project manager is a hobbyist, so he’ll allocate his time as he pleases” which also translates to “partially” checking the users needs, based on the importance that the components had for HIM! In other words, instead of prioritizing globally, he prioritized among tickets from select components of the project, leaving other components behind.

Taking it a step further…how does a person become involved with development of an FOSS? Well, firstly one needs to find the FOSS. There are many ways and reasons one may find a project, but it is probably fair to say that two are the most common:
a) A Person has a need for a tool (as a user), searches around, and lands on an Open Source project. First becoming associated with the project as a mere user, he/she eventually decides that he/she can donate some free time and utilize his/her skills to make the project “better”.
b) A person knows he/she wants to develop a certain type of project and searches for existing solutions or initiated efforts. Then joins the original team being happy to have found it.

Among those two, #a is by far more common (in my experience at least). So…you have a bunch of hobbyists who started as users (i.e. have or at least had a personal need for the product) and are now building it. This is the devs developing for themselves aspect…Fine…but what happens when the #a case is a Project Manager?

Even if one attempts to be objective, even if one is a highly experienced Project Manager who KNOWS how to deal with users and devs, the whole process changes when he/she is a user him/herself! As a hobbyist, there is a limitation in the time allocated and often in the attitude with which time is allocated. As a user, there is an implicit subjectivity…one will always want to push forward features that are more important for one’s own person. Then there is the sub-component bias, as I mentioned earlier. Given limited hobbyist time, one may only deal with 1 part of the project, doing a great and objective job there, perhaps, but having made the subcomponent choice more subjectively.

And finally, even if the Project Manager is 100% excellent in the job…there is no guarantee than devs will WANT to listen to him/her. Because of all of the above (and more) reasons and expected behaviors, devs are (or may grow to be) biased in treating the Project Manager as a mere user, even if he/she had been accepted as a non-coding team member. In that case, it doesn’t matter how objective the Project Manager is. The recommendations are perceived as subjective and are as ignorable as the loud voices of the “270 out of 11000 users”.