Free Software’s Hidden Burden

I’m one of two developers on an open source project.  I’m going to try to be as vague as possible about the project, because the stimulus of this post is some developer politics that aren’t particularly important.  However, some background is required for some issues that I wish to bring up.  I’ve been a part of this project for about two months now, and have gradually been introducing bigger and more intrusive changes.  Recently, the other developer has begun to disagree with some of my commits, and as of today has informed me (in no uncertain terms) that I should stick to certain key areas of the source code, and avoid touching anything else.  If I have changes I want to make outside of my designated area, I should send a patch, which he will modify to his satisfaction and check it in.

Personally, I find this grating.  I’ve poured my soul into this project for the past two months, and I feel like I’ve got a really good handle on the code base.  I’m happy to discuss changes I want to make or have made, but this feels like I’m on probation because my attempts to improve the project conflicted with the lead developer’s vision.

Let’s ignore whether either of us in the right here, and concentrate on what possible courses of action I have available to me.  I can:

  1. suck it up and keep working for the project’s benefit
  2. pout and refuse to contribute under these conditions
  3. fork the project, and take control of my own destiny

Option 3 is often touted as a fundamental right of any Free Software developer.  Since the code is completely open, anyone can take a snapshot of a project and make it their own.  This is a drastic measure, but sometimes a necessary one in cases where a hostile developer is actively stifling further work.  Leaving aside the question of the right choice in this situation, I realized today the problem with forking that is not considered by most people who evangelize Free Software’s benefits: the brand.

The project of which I am a part has a brand.  We receive 20-30 downloads per day, there is a Sourceforge page, a bug tracker, user forums, and more.  The lead developer is in control of all of this, meaning that a fork will lose it all.  This severely limits the efficacy of a fork – why bother working on something if nobody’s going to use it?  Any user will almost certainly find the original project before coming across my fork, so there’s precious little motivation for me besides “I want to be my own boss.”

While this is an isolated incident, and I haven’t spoken to anybody else about it, I would be interested to find out whether this is a legitimate concern for other projects.  The right to fork is great, but it’s wasted if there’s too much tying you down.

24 Responses to “Free Software’s Hidden Burden”

  1. Is this specific to open source/voluntary projects?

    If this was a commercial project, the other developper, would be the senior developer, team lead and you would be the junior developer. Your only option would be to complain to upper management, which is probably a PHB who has not a clue and would trust the senior developer more than you. The only difference is in an open source project you can fork whereas in a commercial setting it would most probably breach your employment agreement and get you in big trouble.

  2. I guess it depends on how big the changes you want to make are. If it is merely minor patching and fixing rather than major functionality I stick with the project. If you have a bigger and better vision then why not take the fork – will your differences give your fork an edge over the existing brand version? Who knows your fork could become adopted as the better one?

  3. You have a fourth option. You can continue working committing parts that the two of you agree about, and have (and publicise) a separate set of patches that can be applied to to the mainline (and keep that in sync all the time, so you don’t end with defacto fork).
    Linux kernel people do that all the time (and Ubuntu does it to Debian all the time).

    If your work is meaningful to the users, they’ll tell you (*and* the other guy), distributors might pull in your patches when they create packages of the software, etc. So if everyone starts using your patches, the other developer will probably have to rethink his position (on the other hand, if the changes you were making, though worthwile, aren’t needed very much, in which case you’ll have a feedback on what the users would like more)

  4. Fork it! That’s what open source is all about.

  5. Suck it up and send a patch. Development works better when each specific piece of code is owned by one person who can review all changes before they are applied.

  6. Not being a developer, I’m a coming up a little short.

    I am noticing that these might be issues of HUMANITY, or at least the human parts of a free software project. Getting users attention, marketing, your secondary status to the main developer, all are coming up if I push aside your vision and a possibly technically superior program.

    I really would think you could find better, but stick it out and make sure while you look for another project (maybe a fork of this one) to spend your time on. forks can succeed, but its often a human issue to get people to notice it. Try and leave this project gracefully, even if the other partner does not.

    The other commenter relates human issues as well. Human issues are the hardest and you would be lucky to find a How-to on the internet, or even from your family or friends.
    good luck

  7. Reformat all of his code. e.g. change the brace style, spaces to tabs -or- vice versa, and randomly rename 20% of the functions & variables. Mostly with names like bobSucks (assuming the other person’s name is bob). Combine a few separate files into one, and then split some others up. Give the files names like, f***OffBob.whateverdude.(extension)

  8. You’re a student. Chances are you’re not anywhere near the programmer you think you are. Suck it up and learn.

    Also:
    Two months is nothing.
    Open source is for fools.

  9. Stop working on the project completely. Fond some other project to work on.

  10. I would say to choose option 4.

    4. Talk to the project leader about why he has restricted you.

    Maybe you can resolve the internal struggle you are dealing with.

  11. @Eric: Been there, done that. Didn’t make a difference. Honestly, this post wasn’t meant to be a kind of group therapy session for me. I just wanted to share my insight into how the ability to fork may not be all that it’s cracked up to be.

  12. I think, or hope anyway, that we are entering an age where the idea of “fork” doesn’t need to carry as much weight. With services like git hosting where anyone can fork anything and work on it for a bit, and then post to the list to say, “hey this is how I solved this, grab it if you want”, we no longer need permission to push things to a central place, and we no longer need to agree on everything. You should branch off the pieces that you think you did better. Don’t think of it as a “fork”, thing of it as a light-weight experimental change. People on the list can argue about which version is better, and eventually there will be a winner.

    Spend some time on the git mailing list.. every single patch to the software is posted there before it is merged into the main codebase. Everyone working on git works on their own tree and then submits patches to the mailing list, it’s the only way to get your code into the software. Therefore everyone working on git is able to review everyone else’s code and say yay or nay before it hits the mainline.

    Unfortunately you’re suffering from not having enough developers on your project to discuss things with. It’s better to bounce ideas off of 3 or 4 people, rather than just one other, who can say yes or no. On the other hand, you should also consider very carefully the lead developer’s reasons for his decision. Maybe he has good reasons, a different direction for the project than you had considered. It’s important with such a low number of developers that a real vision is shared between you, otherwise you’ll just get confused. But in the meantime, feel free to make a lightweight fork, and show tell him and others to check it out.

  13. @Steve: That’s a really good point, and I’m a fan of development models like that (I hang out on the Bazaar mailing list which is handled the same way). However, as you said, with only one other developer who has specifically vetoed any of my proposed infrastructure changes, a lightweight fork will really only be for my own benefit. The changes I want to make are for developers only, so there’s really no way to gain any traction with it.

  14. if you have a brand you should be doing code reviews, which means sending patches

  15. Up until now we’ve been doing post-reviews, ie. reading over the diffs in SF’s ViewVC instance.

  16. You’re commits are just internal infrastructure changes, you are the only developer apart from the leader and you have been part of the project for just two months? I’d vote 1. suck it up and keep working for the projects benefit!

    If you’re changes are groundwork for some user-visible features or debugging gets easier, you should be able to persuade her by technical reasons. Other changes make it harder for the leader to keep an overview over the architecture, which is bad for the project.

  17. If your code contributions are really that much better than the lead developer’s, then if you fork, the superiority of your fork should begin to draw users.

    Note that this is not a problem peculiar with Free Software. Anytime you work on a development team, there is potential for this kind of disagreement and stifling. A least on Free Software, you have the option to fork. In the commercial world it is almost never possible.

  18. 4. Ask him to review the code, letting you make the changes and committing. Tweaking other people’s code does not teach them as much (even if, in the case in point, you would then go and see what he changed), because when your code is reviewed you *think* about the changes and the rationale.

  19. Uhm, I just read in the comments that you want to make some core changes. Then, agree with the lead developer to fork momentarily just to show him why you want those changes. Chances are that, if he’s a good guy, he’ll come up with a better design, or will accept yours after understanding it better.

    In any case, the important thing is that you keep feeling the challenge and having fun! That’s the most important thing when writing free software voluntarily.

  20. @Greg: As you say, these sorts of problems are universal among projects. However, I was attempting to point out that the benefits of forking as evangelized by Free Software enthusiasts are reduced by the factors I discuss near the end of the post.

  21. Josh Matthews Says:
    “However, I was attempting to point out that the benefits of forking as evangelized by Free Software enthusiasts are reduced by the factors I discuss near the end of the post.”

    Atleast free software gives you an option. The fact that your fork will not be instantaneously popular as the parent is not really an open source issue. It would need better marketing. Say if you are an influential blogger, your fork might be even more popular than the parent. Hence I truly doubt your assumption that “nobody’s going to use it”.

    If there are like minded individuals like you then without much self-induced marketting your fork might get the attention it deserves. Not sure if your PHB would appreciate this, of course :)

  22. Hi,

    There seems to be two levels to this discussion: 1) the external/popular perception of the new fork and 2) the internal relationships of the development team. Yet both of these are defined by the overall “vision” of the project. From your own comments, it seems that the scope of your ‘vision’ of “what should happen” is limited to some details of the internal code structure, whereas the lead developers sense of vision includes the whole project and its longer term future.

    Since (by your admission) your proposed changes have no user visable impact and since this is explicitly outside of your scope of concern, it seems a little odd and unlikely that you should be at all concerned with how the general public percieve your version. Presenting to them a functionally equivilant version would seem to cast you as a simple copycat, — you will be percieved as an egomaniac trying to steal focus from an established and legitimate project. The lead developer owns the ‘brand’ because his vision happened to include those aspects within its scope. If you want your own brand, you will need to develop your own vision for one.

    However, I think that what gets me the most is your comment “I’ve poured my soul into this project for the past two months…”, with the implication that you should therefore get “full privelages” to do whatever you want, regardless. It would seem to me that the lead developer has also already put in at least this much effort, and probably many many times more. What gives you the right to disregard all of that, so as to call your own ideas/vision as somehow equal to that of the founder? As noted above, if your vision is not so well nuanced so as to include *all* aspects of the project, including the overall purpose, user functionality, and the brand, you would do well to _follow_, rather than to try to lead.
    Your opinions are merely tactical — they are not strategic. It takes both to win.

    Therefore, my recommentation to you would be to “suck it up”, and _acknoledge_ that you *are* actually on probation. If I was a project leader, and I found out that someone on my team had so little respect for my vision of the project, or for me as a team leader, I would seriously consider whether it was really “worth it” in the long run to keep that person on board. What president would want to keep around a general who will try at the least oppertunity to oust him? While it is important for a team leader (or any
    leader) to earn your trust, it is also important for you to _give_ that trust and loyalty when it *has* been earned. If you trust the leaders vision, you will find that sometimes it is necessary to do what the leader asks, even if you disagree. The leader may not have the time, or the capability, or even the responsibility of discribing, explaining, or convincing you of the ‘rightness’ of the vision. You may ask for these things, but it is problematic to /demand/ them. Sometimes vision, or any creative process for that matter, is subtle and hard to articulate — even when it is very nuanced and coherent with the truth of the world.

    Even though a project may be ‘open source’, the project ‘belongs’ to the founder, since by inciting it, he bears ultimate responsibility for it. Whereas in any reasonable situation, the degree of responsibility must be matched by the degree of authority, the founder must have the oppertunity to have the final say as well. If you want your own project, you must start your own project — and that includes a new brand, a new user community, etc, etc. If your vision is not so expansive as to include all of that, consider your situation an oppertunity to learn from someone who clearly *does* have that sort of vision.

    I think that a sense of true, honest and genuine humility on your part will really help *all* aspects of the situatiuon, regardless of whatever else many be going on.

    F

  23. Good question Josh.

    If this project is getting 20-30 downloads a day, it is a successful project. Over time, it may even need somebody to do paid support and customization. As the number 2 banana on the project, you are a good candidate to pay for support and customization.

    If you fork, you control your own destiny. That includes building market trust and awareness to the point of getting 20-30 downloads a day. Once you do that, you are the king of your hill, but it will take an unpredictable amount of time.

    Your decision depends on what you want out of the project. With the first option, you become known as the number 2 banana on a successful project, which is valuable for your paid career. At the cost of not having architectural authority, you get the benefits of the project’s success for free. With the second option, you get to learn for free what it takes to own the architectural authority of a project as well as what it takes to market it. You will learn this whether you succeed or fail. The second option can also be good for your career, but in a different way.

    You have to decide what you want before you make a choice “…to fork or not to fork”.

  24. I am not now a software developer (so anything I write is basically just for fun), but back in the day (at the dawn of software engineering as a discipline) I witnessed the following project: A group of government scientists and a group of professional programmers worked on equal parts of a complicated military control system. There were 4 government scientists and 6 contract programmers from a defense contractor. The project was expected to take two years. At six months into the project, the status was this:
    The government side was finished and bug free, the contractors did not have a working stub. What were the differences?
    Programming skill: The government side used Scientists who were not trained programmers (although they were uncommonly bright) The contractor used trained professional programmers: Advantage contractor.
    Methodology: The government side used an egoless team construct where every bit of code was reviewed by at least one team member, and was open for review to all team members. The contractor used a methodology where each team member was responsible only to himself and without review. Advantage: government.

    Do not pass up the opportunity to have someone else review your work.

Leave a Reply