Forgot your password?
typodupeerror
Open Source Businesses Programming

Ask Slashdot: Corporate Open Source Policy? 57

Posted by Unknown Lamer
from the in-the-open dept.
Phiro69 (3782875) writes Does anyone have any best practices/experience they would like to share on how their corporate entity put Open Source Software out on the Internet? Historically at my engineering firm, we've followed a model where we internally build a 1.0 release of something we want to open source, the product owner and legal perform a deep review of the release, and we push it out to a platform like Github where it typically sits and rusts.

Our engineering interns have started down a new path: Using Github from the beginning (I set the repo private), and, after a bare minimum is completed, flipping the repo public and continuing development in the open using Github. How do PO and Legal reviews fit in? How can we ensure we're not exposing ourselves or diluting our IP if we're doing semi-constant development, publicly, sans a heavily gated review process? What does everyone else do? Or does corporate America avoid this entire opportunity/entanglement/briar patch?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Corporate Open Source Policy?

Comments Filter:
  • CLA (Score:4, Insightful)

    by Rinisari (521266) on Wednesday August 13, 2014 @12:29PM (#47664311) Homepage Journal

    Having a solid Contributor License Agreement process in place would probably be a good idea. That way, it's clear who owns the code that comes in and encourages people to contribute while defining a (necessary evil) process for doing so. You'll lose random passers-by, but just one passer-by who gets litigious could be more of a headache than it's worth.

    • by jjn1056 (85209)

      Having a solid Contributor License Agreement process in place would probably be a good idea. That way, it's clear who owns the code that comes in and encourages people to contribute while defining a (necessary evil) process for doing so. You'll lose random passers-by, but just one passer-by who gets litigious could be more of a headache than it's worth.

      I'm not sure if the idea of a contributor license as you suggest is in the spirit of open source.

      • by unrtst (777550)

        I'm not sure if the idea of a contributor license as you suggest is in the spirit of open source.

        Depends on which "spirit of open source" you are referring.

        The classical Richard Stallman model is about giving the person running the code the ability to modify it for their own use and share those modifications with others. I believe that one of his first big gripes had to do with printer drivers, as an example. In that case, the contributor license agreement causes no harm at all. The CLA defines restrictions for the user if the user wants his contribution to become part of the codebase distributed by th

      • by Junta (36770)

        CLA with copyright assignment opens the door to have your contributions abused by the copyright holders.

        CLA without copyright assignment is usually just the 'project' covering their ass in case of problematic contributions that infringe copyright or patents.

      • by T.E.D. (34228)

        I'm not sure if the idea of a contributor license as you suggest is in the spirit of open source

        Perhaps you should share your qualms with the good folks over at the Free Software Foundation, since they insist on them as well [gnu.org].

    • by kthreadd (1558445)

      It will keep the lawyers happy, but expect to receive less attention or even be completely ignored if your project is very small. Lots of people will simply not sign CLAs.

      • by ron_ivi (607351)
        Not the lawyer concerned about if the company should be paying those workers minimum wages.

        (or maybe the lawyer will be happy - but the guy payhing the lawyer won't be)

    • by ron_ivi (607351)

      clear who owns the code

      Do you have an example of a good Contributor License Agreement that doesn't just sound like "do work for us and we'll pay you less than minimum wage"?

      Wouldn't it be better to just stick to a mainstream F/OSS license; and he users agree to release their code under that license?

      • by Junta (36770)

        The general intent of many CLAs is some stuff to make the contributor attest that he isn't doing something like injecting patented capability or violating someone's copyright. The key distinction between an open source licensed product being redistributed by someone who adds problematic capability versus having that capability injected directly is that the curator of that project is the one that gets sued in the latter case. So if stuff is bolted on but not coming back, the weaker assurance of GPL or BSD

    • by ciascu (1345429)

      Just to contrast with Copyright Assignment, which is also a popular approach, there can be a substantial body of improvement that the upstream developers are unlikely to even be notified about, never mind receive, because requiring Copyright Assigment leaves it dead in the water. This may seem like a bit of paper for a lone developer, but when an institution or external agreements are involved, it takes one person somewhere in the chain, who may not know or care, to say, "Why are we signing away ownership o

  • by halivar (535827) <bfelger.gmail@com> on Wednesday August 13, 2014 @12:36PM (#47664355) Homepage

    I'd do some research and find out what other projects have had issues with. In particular, make sure you actually own the copyrights or have a distribution license for everything you intend to open source. All it takes is one lazy cowboy coder and Google to screw your whole project. Also, understand the license you intend to distribute under, and what licenses are incompatible with it.

  • My company has released a handful of open source projects that are mostly used by us. But we just release them as open source from the start. Part of the rationale behind that is that each of the libraries are meant to implement some kind of protocol or perform some specific, but generic, functionality that we wouldn't mind feedback on early in the development process. So, we just do them as open source from the first line of code that is committed. No legal review, just the developers that will be working
  • by bill_mcgonigle (4333) * on Wednesday August 13, 2014 @12:52PM (#47664469) Homepage Journal

    Or does corporate America avoid this entire opportunity/entanglement/briar patch?

    Yes, to a large degree, and they're stuck in the last century. IP has always been an imaginary government monopoly meant to enhance the business interests of a certain caste; originally that was the author/inventor, but that ship has long sailed - now it's corporate profits almost exclusively (and you may find exceptions that prove the rule).

    The next century will be on the Internet and artificial scarcity will be seen as a quixotic relic. Understand this and move forward - businesses that do will outcompete businesses that don't because they're going with nature, not against it. You do still need to keep yourself out of courts, because the death throes of the old corporations will be violent, but use your legal team as protection from other corporations, not protection from customers.

    If your company cannot embrace the future and *you* get it, then that's a great signal to move on to a place with a positive slope. These are, of course, long-term trends, but fighting the brushfires of a losing battle is no way to spend one's life.

    • by mi (197448)

      originally that was the author/inventor, but that ship has long sailed - now it's corporate profits almost exclusively

      The "inventor vs. corporation" distinction you are trying to make is without difference [logicallyfallacious.com]. For an inventor to use his invention — whether he himself forms a company to profit from it or sells the invention to an existing company — either way the intellectual property must be controlled by him initially. In this regard nothing has changed since "last century".

      We know, what was ha

    • by Kjella (173770)

      The next century will be on the Internet and artificial scarcity will be seen as a quixotic relic.

      Unless the future is the cloud, web services, central game servers, always-on DRM and remote attestation where essential bits of the code don't run on your machine. Any "Secure Boot" Windows 8 machine now comes with a TPM chip active to support this, in a generation or two I'm sure they'll make it a requirement. If you've tampered with your PC, no Netflix/Spotify/Steam for you. Same with Android, install AOSP all you like but it won't be able to fake the signatures.

    • by westlake (615356)

      IP has always been an imaginary government monopoly meant to enhance the business interests of a certain caste; originally that was the author/inventor, but that ship has long sailed - now it's corporate profits almost exclusively (and you may find exceptions that prove the rule.

      There is nothing imaginary about the power backing up your ownership of a patent, a copyright, a quarter acre lot or a '57 Chevrolet Bel Air.

      I have never understood how a geek manages to survive in a digital universe without coming to grips with the fundamental differences between the intangible and the imaginary.

  • by Vellmont (569020) on Wednesday August 13, 2014 @01:02PM (#47664547) Homepage

    Your question is far too generalized. You don't mention what your product is, what your firm does, or what the risks you're trying to protect from. Nobody can give you any meaninful advice unless you provide real details. What is it you're afraid of exposing? What's the IP you're afraid of diluting? Is your company a 100 person shop, or a 10,000 person shop? It matters.

    Those risks may be illusory, depending on what this code is. I've had a few project I'd like to release as OSS, but there's zero IP dilution and zero risk of exposing anything. Despite what people tend to think, code isn't a commodity. The specifics matter quite a bit. The only answers you're going to get with the information you provided are very generalized useless ones.

  • by Anonymous Coward

    Make your public repo controlled by legal so they approve what goes out. Have the public one be a fork of your private repo. So you make changes to the private repo, have legal review, and push approved code to the public one.

  • by PCM2 (4486) on Wednesday August 13, 2014 @01:15PM (#47664645) Homepage

    Your comment about "pushing it to a platform like Github where it typically sits and rusts" is telling. What do you think will really change if you just shift when you push your code to Github?

    In a nutshell, "if you build it, they will come" is a nice fantasy, nothing more.

    Even very high-profile open source projects often have very few contributors outside of the companies that first created them.

    And I don't think the problem is that these projects don't get community developers on board soon enough. Why would a hobbyist or other unpaid developer risk devoting time and resources to a project that is mostly vaporware?

    The problem is that it's very difficult to get unaffiliated developers to commit to working on something -- especially business software -- when there's no real incentive other than "someday this may end up being a product that your company might decide to evaluate to see if it might be possible to use instead of the commercial alternative that it has already sunk capital into and has been using for the last five years."

    • Re:Rust (Score:4, Insightful)

      by Junta (36770) on Wednesday August 13, 2014 @02:20PM (#47665157)

      One issue is that generally such projects are actually pretty niche and get developed with only that niche in mind. There simply isn't a pool of eager developers to tackle only your specific issue.

      If you can think about modularity and develop some key components that are more generally useful as distinct projects, you may have better luck.

      But overall, open source building a large development community for any given single project is generally the exception rather than the rule, even if you do your best. Even very ubiquitous projects that play a role in nearly every linux system often has maybe one or two developers that are really familiar with it.

    • You really do need to initially invest in building some community, if you want a community who will provide bug fixes and new features for you. It doesn't need to be a large community. Two or three or other companies / developers using the software, sharing development costs, can make a big difference. That can provide the critical mass to keep the project going and attract occasional contributors.

      My primary job is working on specific open source software. The larger framework is used by many organizatio

  • Do not become the next Sergey Aleynikov [wikipedia.org]. He was acquitted, but not without a huge impact on his life.

  • One thing I notice is that sometimes a company decides to open source some in-house crapware because they heard its a good way to get free publicity and perhaps attract more developers. Quite often the project ends up with zero adoption because its not that interesting and often there's a bunch of existing projects with already built communities that are doing more or less the same thing. Or the focus is so narrow that it solves nobody's problem. What usually tell people is that its better to learn to co

  • Pushing to Github is nice and all but for a project to get any type of traction you need to tell people about what problem it helps to solve, show them how, and ideally make it easy for them to try it. Something up on a corporate blog. Compare it to other solutions. Have an instructional site in your space review it and write about it.

    Unless you can show what it does and then differentiate why it's better than existing options, rust is exactly what will happen.

  • My former company's policy was to remove all comments and documentation before making the code public.

  • by Michael Tiemann (3136525) on Wednesday August 13, 2014 @02:46PM (#47665393)
    I made my first open source contributions back in 1987, and I did so not by launching a new project, but by contributing to an existing project (GNU). Over time, those contributions took on a life of their own (GNU C++). It was quite some time (after starting Cygnus) that we had any need to launch new open source projects (such as automake, configure, Deja GNU, etc.) My recommendation for corp OSS folks is (1) figure out how to make what you need out of existing projects and do that. If/when you reach those limits, explain the new problem you are trying to solve, see if there's interest (or even an existing solution), and then work from there. But never stop contributing to the ecosystem that likely surrounds the new code you're trying to launch. If you only ever work on your own code, people will reciprocate by only working on their own code toward you. If you work on your own code and help improve the code that lives around it, you may well find many who want to join your project, too.
  • At Odoo, the Open Source ERP [odoo.com], we work with around 1000 partners and/or customers that have a dedicated IT department developing Odoo modules/apps. From my past experience working with them, I would say that it's less about contribution than collaboration.

    Some companies think that it's good to contribute to open source (for different reasons) and they just do that. It's usually a big failure as nobody uses their code and they get nothing from having published their development. The main reason is that some

Business is a good game -- lots of competition and minimum of rules. You keep score with money. -- Nolan Bushnell, founder of Atari

Working...