8

Consider this situation.

A person has created a repository for a open-source project with a large scope. This person has project management experience and reportedly has development experience, and is enthusiastic about creating this project (for various reasons). However, this person is not well-versed in the target language, or framework.

As such, the person in question decides to "recruit" others to help with the project, while attempting to contribute through providing "management" to other contributors (via timelines, documentation, communication management - holdovers from a non-distributed, classical system). Unfortunately, the person also contributes little to no code despite owning the repository, instead depending solely on the contributors to make contributions; and so the project doesn't grow (since there are few contributors). The idea is that after the project has started, a timeline has been set, and code has been contributed, the project owner will be comfortable enough to begin to contribute.

This mindset seems counter to the way projects gain momentum in the wild, where people get excited after some work has been done. Further, due to the lack of development familiarity on the owner's part, the project basically has no momentum without other contributors (which is the cause for the timelines, the documentation, and the other management tools in place; perhaps recruitment would not be necessary with a larger development skillset).

How can a contributor address this situation (without leaving the project or forking the original repository into oblivion)?

Edit: To clarify, this scenario occurs in a non-business, non-corporate, online environment where contributors are geographically disparate and communication is unscheduled. While there is an "organization", it has been created by the repository owner and the project license would be non-restrictive. There is no compensation for contributors.

Improve this question
16
  • 1
    Great question! I just have one question for you: Is the project maintained in a workplace environment, where ownership (and sometimes copyright) fall under the organization? Or is this a more "casual" environment, where any communications are online, and the manager relies on external contributions for the work? Those are distinct situations, and I think the question would improve significantly if you add that to your question, as my answer would definitely differ.
    – Zizouz212
    Nov 10, 2015 at 22:52
  • In this scenario, it is most definitely the latter.
    – user3243
    Nov 10, 2015 at 23:06
  • 3
    Fork it, and get rid of the "manager" if he isn't adding value.
    – vonbrand
    Nov 10, 2015 at 23:23
  • 2
    Interesting question. My initial reaction is "fork it", but you're explicitly asking for another solution. Is this "project manager" the only one who can accept pull requests? If so, that's a problem, because the project will need technical leadership. Someone to keep the code quality high.
    – RubberDuck
    Nov 11, 2015 at 0:10
  • 3
    From what I'm reading, the project manager is providing little value, and there's a lack of technical contributors. Isn't the solution to get more technical contributors, instead of getting rid of the project manager? Are you under the assumption that the project manager is somehow providing negative value? What's with the scare quotes anyway?
    – congusbongus
    Nov 11, 2015 at 0:59

3 Answers 3

Reset to default
9

Project management, whether in closed or open development projects, is a hugely valuable role. Therefore, the way you deal with project managers is simple: value their presence, and try to keep them around as long as possible. The lack of project managers in typical open source projects doesn't mean their work is irrelevant; on the contrary, due to the distributed and volunteer nature of open source projects, project management is more important.

The activities that you attribute to this project manager: recruitment, planning, documentation, communication, are extremely valuable tasks. How can you have code contributions if no developers have been recruited? How do you make sure the right work has been done without timelines and planning? How do you expect to get a healthy stream of code contributions from non-core developers if you have no documentation?

So from the facts you've presented in your question, I don't see what the problem is. Project management in open source projects can be very different from closed source ones, because you usually don't have a bag of money to hire developers to work on whatever you tell them, and the developers you do have are volunteer and can come and go without notice. This makes project management more challenging but no less valuable.

There's nothing wrong with a repo owner who doesn't contribute code. Linus for example basically doesn't read code anymore, let alone write them, and yet he's hugely important for the Linux project and still makes important decisions. The only requirement for a repo owner is that they are someone you can trust to either make final decisions, or defer to those who have the expertise and judgement to make them. The fact that your project manager recognises their lack of technical expertise and is holding off from making code contributions is a good thing.

The only real problem that exists in your scenario is that there's a lack of code contributions, which is a problem in many open source projects regardless of whether the owner is a developer or not. The solution to that is to get more code contributions, not to find fault with the project manager and what they're not doing.

Improve this answer
3
  • 3
    This is a great answer, and it addresses a lot of the strengths of project management. However, based on my experiences, some of this can be detrimental in the very early stages. Sure, Linus manages, but originally, he was the one building Linux - not recruiting people to build it for him. He moved into the management role after the project gained popularity and momentum. In this case, it seems as though we're trying to put the cart before the horse - so instead of actually getting results quickly, efficiently, and effectively, we're mired in documentation hell.
    – user3243
    Nov 12, 2015 at 15:37
  • I agree that certain standards are very important - code quality, code style, public-facing documentation - but I think that those things tend to be addressed naturally in the early stages of a project. However, writing guides describing how to build a component (essentially, for people uncomfortable with development), guides that essentially duplicate existing framework and feature documentation - I would not find that necessary or helpful, and I think that's one of the main problems here.
    – user3243
    Nov 12, 2015 at 15:42
  • 1
    @jedd.ahyoung as someone who has contributed to dozens of projects, none of those things get "addressed naturally".
    – Josh Berkus
    Oct 23, 2018 at 18:05
3

This is a classic "do this for me" situation. It's very unhealthy: Imagine a school student who doesn't understand how to write a simple script. Someone else writes it for them, and this original school student now gets the complete credit for the working script.

It's the same idea here. Contributors are literally providing code to a project, where an inactive person is literally getting all the credit. I hate to say this, but you've really been doing free work for this "manager".

Right now, contributors have been writing code, satisfying the needs and wants of the manager. It sounds like a workplace environment: you need to "do this and that" by "so and so date", and that's very unhealthy. From what I understand, it looks like it's been near impossible if contributors have had interests that they wanted to have in the project. Is the "manager's" agenda going to stop that? If the manager doesn't like it, he'll say no, and you will have one unhappy contributor.

The "manager" is just meta-managing, and I don't see any incentive from him to start contributing anytime soon. By setting schedules and goals, he sounds more interested in the logistics of the project, rather than the code base, which means that by contributing, he'll just be a "newbie." One that will have to be taught the base step by step so that he can start making some minor changes.

From the comments, it looks as if the "manager" has others' approving commits, and acting like maintainers to the project. This just worsens the "manager's" position: that he has no sense of the quality or efficiency of the contributions to his project. It shows a lack of commitment and dedication to the project, in that the maintainer doesn't know the internal structures of the code base. If he were to issue a drastic change as a part of his agenda, it may not even be efficient for the contributing to try to implement such a change, as it wouldn't be efficient. Such workarounds would just dirty the code, making it unattractive, and after a period of time, unusable.

I understand that you want to make this work, and I applaud you for that. Many people would literally just give up, so this shows that you still have faith.

Take the time to reflect:

  • Is contributing to the project worthwhile? Is benefiting you?
  • Do you have a sense of pride or ownership in the project?
  • Is there clear communication? Are you, as well as other contributors, able to discuss segments of the agenda?
  • Do you feel like you have a voice - that you can raise your concerns and ideas without having any doubts in mind?

If you answered no to any of the questions (especially the last), I would say that there is ground for concern.

In that case, I would recommend the following:

  • Communicate with the other contributors.

    Do other contributors share your concerns? What are these concerns? By collaborating and communicating your thoughts with other people involved in the project, you'll understand the feel and attitude. With people that are basically equal to you in the project hierarchy, you'll feel more at ease to do this.

  • Talk to your manager.

    Figure out your manager's position? Chances are that there could be a reason as to why he doesn't contribute. Does he feel like the project is advancing? Get a feel for his point of view. This will allow you to share and think about any concerns that the two of you have. Once you feel like you've got more information, you'll be able to make more rational decisions as well. Ask him why he still maintains this project, and what his driving force is for setting goals, objectives, and timelines, as well as keeping the repository under his name.

If the community begins to have a sense of understanding, it will improve. Open source development is something I find similar to community development: the project is a collaborative effort between people who share the same ideas and goals, and who wish to improve something.

If all else fails, and you (or other contributors) feel dissatisfied, fork the project. This does you no harm, and you will have more of a say in how the software can move forward. There are still people involved that will be able to support the project. If you do this, I would make sure to say why, and to outline all your concerns, as well as (briefly), any efforts or attempts that you have made to rectify them. Have fun with that new project!

Regardless of the action that you take, keep an open mind. Be open, think positively and think straight, and make sure that you put your best foot forward.

Improve this answer
2
  • I think you are really underestimating the value proper project management can have for an open source project.
    – Philipp
    Nov 13, 2015 at 23:14
  • @Philipp I don't think I'm underestimating project management, but I'm simply critiquing what I think is bad project management. From what I hear, it doesn't look like there's proper management here. Bad project management simply removes value from a project.
    – Zizouz212
    Nov 15, 2015 at 16:54
1

In your comment, you say you would like for the project to require less documentation to move faster, and more efficiently, so try to strive for that.

If you believe this is holding back the project, the only thing you can do from within the project is talking, and discussing to do less of it. You could talk to them directly, or even open a bug on the issue to attract wider discussion. If you come to an agreement to do that, than that's settled, and the problem solved.

If you don't come to an agreement as a project, or you're unhappy with the outcome of the agreement, forking is always an option.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.