Announcement

Collapse
No announcement yet.

Company I work for is looking to contribute to Open Source projects... but wrongly?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Company I work for is looking to contribute to Open Source projects... but wrongly?

    I would like opinions on this. One of the managers where I work wants to 'enhance' some open source projects, but instead of going by what I would consider the normal route of supplying patches upstream, he wants to open a bitbucket account and grab the project (he never told me which one) and then just enhance it. While this would still be 'open source', to me this is the very definition of a fork.

    He claims that it'd take too long to wait for upstream to apply any enhancements, and depending on the project, that could very well be correct. But I told him he didn't technically need to wait for such things. All that would be required is to at least provide links to whomever the software was distributed to for the source code, or even just the patches made, and the upstream source. He only mentioned in the discussion LGPL section 4 (which is the one conveniently linked to on Wikipedia). I suggested they develop the patches internally, build the project and distribute it to the customers, providing links to the bug tracker or mailing list or wherever those patches may be. Then the end users can get the enhanced software sooner, they don't have to wait for upstream, but they also don't end up doing a full on fork! Unless of course their patches get refused outright, then at least they'd have a reason for forking.

    What does everyone think about this? This is a manager that has always liked to disagree with me, and being an Apple fan and a developer, I don't think he's delved into a whole lot of open source software, at least the licensing and developing side of things.

    leech

  • #2
    There's nothing wrong with forking the software, except you'll then have to merge in any future changes from upstream. Whether that's easier than getting your changes incorporated will depend on who's in charge of that project.

    Comment


    • #3
      Having a public fork is IMHO better, as then everyone has access to your changes, not merely your customers.

      Comment


      • #4
        Originally posted by curaga View Post
        Having a public fork is IMHO better, as then everyone has access to your changes, not merely your customers.
        I would think this would only apply if they had first attempted to contact the upstream project. If they had decided to not utilize any enhancements, then I would have had no problem with them creating a public fork. Also, without code review from the original project, I think any sort of fork would suffer.

        leech

        Comment


        • #5
          Originally posted by leech View Post
          One of the managers where I work wants to 'enhance' some open source projects, but instead of going by what I would consider the normal route of supplying patches upstream, he wants to open a bitbucket account and grab the project (he never told me which one) and then just enhance it. While this would still be 'open source', to me this is the very definition of a fork.
          I would wait until you know which project and, more importantly, which enhancements. At first glance there are probably 3 buckets :

          1. General improvements which would be likely to be accepted upstream, where your reason for forking is because the effort of getting changes upstream seems (a) scary/undefined and (b) likely to be a poor investment.

          2. General improvements which would be likely to be accepted upstream, but where your reason for forking is to gain competitive advantage by having "first dibs" on the improvements.

          3. Customizations or deviations which would probably not be desired upstream anyways.

          Case 1 is pretty simple -- you mostly need to make sure that the work required to get changes is clearly understood and at least lightly validated with the upstream community. At that point you can usually make a business case that the benefits of going upstream outweigh the costs -- it's just hard to make that sale when the costs are fuzzy

          For case 2 it's going to appear at first that forking is the preferred approach, but you need to look at (a) how quickly the upstream project evolves and (b) how often you are going to have to resync with the newest upstream in order to meet customer expectations. In this case one approach would be to push upstream but to time your product release cycles so that you get at least short term advantage from the work you do.

          You need to make it clear internally that maintaining a permanent offset from a fast-moving project (while otherwise keeping up with the project) is much more expensive than it first seems... when projects like this are being planned people tend to focus only on the first release, and when you do that forking (wrongly) always seems attractive.

          For case 3 it probably doesn't matter.

          If (as is usual) your project involves a mix of all 3 cases, then the best solution is to architect so that your case 3 changes can be cleanly isolated from the rest, then push everything else upstream where you can.

          If the upstream project is slow-moving then it's much harder to sell the benefits of pushing your work upstream, unfortunately.
          Test signature

          Comment


          • #6
            Originally posted by bridgman View Post
            I would wait until you know which project and, more importantly, which enhancements. At first glance there are probably 3 buckets :

            1. General improvements which would be likely to be accepted upstream, where your reason for forking is because the effort of getting changes upstream seems (a) scary/undefined and (b) likely to be a poor investment.

            2. General improvements which would be likely to be accepted upstream, but where your reason for forking is to gain competitive advantage by having "first dibs" on the improvements.

            3. Customizations or deviations which would probably not be desired upstream anyways.

            Case 1 is pretty simple -- you mostly need to make sure that the work required to get changes is clearly understood and at least lightly validated with the upstream community. At that point you can usually make a business case that the benefits of going upstream outweigh the costs -- it's just hard to make that sale when the costs are fuzzy

            For case 2 it's going to appear at first that forking is the preferred approach, but you need to look at (a) how quickly the upstream project evolves and (b) how often you are going to have to resync with the newest upstream in order to meet customer expectations. In this case one approach would be to push upstream but to time your product release cycles so that you get at least short term advantage from the work you do.

            You need to make it clear internally that maintaining a permanent offset from a fast-moving project (while otherwise keeping up with the project) is much more expensive than it first seems... when projects like this are being planned people tend to focus only on the first release, and when you do that forking (wrongly) always seems attractive.

            For case 3 it probably doesn't matter.

            If (as is usual) your project involves a mix of all 3 cases, then the best solution is to architect so that your case 3 changes can be cleanly isolated from the rest, then push everything else upstream where you can.

            If the upstream project is slow-moving then it's much harder to sell the benefits of pushing your work upstream, unfortunately.

            That is exactly it! Perfectly said! That was my biggest problem with this manager, and also most of why I was irritated at him, he simply wouldn't tell me what the project was, even though I'd asked him multiple times. It could very well be multiple projects. I had suggested to my manager that if the company I worked for wanted support for USB Redirection within the Windows version of the virt-viewer client, that they may just have to give some programmers time to the project. But I highly doubt that has anything to do with this, since this manger I speak of has a team that pretty much only knows Java. I would expect one of the other teams to be better prepared with something that would be more low level, like USB Redirection.

            Indeed if upstream is slow, then I would have no problems with the way they're attempting to do this. I said as much to him, but he still refused to even tell me what the project is. Who knows, maybe they're working on Minecraft plugins.

            slaapliedje

            Comment


            • #7
              Originally posted by movieman View Post
              There's nothing wrong with forking the software, except you'll then have to merge in any future changes from upstream. Whether that's easier than getting your changes incorporated will depend on who's in charge of that project.
              yes on future depends on who's on the project...Agreed

              Comment

              Working...
              X