Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Ask Slashdot: Corporate Open Source Policy?

Unknown Lamer posted about a month ago | from the in-the-open dept.

Open Source 57

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?

cancel ×

57 comments

Sorry! There are no comments related to the filter you selected.

CLA (3, Insightful)

Rinisari (521266) | about a month ago | (#47664311)

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.

Re:CLA (1)

jjn1056 (85209) | about a month ago | (#47664711)

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.

Re:CLA (1)

unrtst (777550) | about a month ago | (#47664971)

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 the original author. That does not stop the user from re-distributing the same codebase with or without his own changes (ie. fork).

In most cases, the CLA will never actually be necessary. Most new projects get few, if any, contributors. The summary even says the works they previously posted just sit there and rust - they aren't maintaining them, and neither is anyone else. On any cases where someone contributes code, it will either be:

a) very trivial, and thus no copyright transfers are needed (ex. a bugfix changing 2 if statements)
b) a small patch.
c) a large patch.

For the large patches, you'll just need to decide if the CLA is worth it or not. Is it a feature that is worth having. If so, is it worth the legal hassle, or should you just rewrite it?

For the small patches, those often need rewritten anyway. People rarely submit complete patches with tests and everything... so just rewrite it. If it's something that doesn't need rewritten, see the previous sentence. Contributors will often provide the patch with a public domain license if asked, which you can then relicense as needed.

Re:CLA (1)

Junta (36770) | about a month ago | (#47665019)

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.

Re:CLA (1)

T.E.D. (34228) | about a month ago | (#47665111)

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] .

Re:CLA (0)

Anonymous Coward | about a month ago | (#47668493)

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] .

Free Software != Open Source

Re:CLA (0)

Anonymous Coward | about a month ago | (#47665565)

He nailed it with "necessary evil".

I'm sure most devs would love to just put all their work out for the world to see with no management of imaginary property rights or ownership. Unfortunately businesses are big into this whole money thing, are really not into the whole risk thing, and when you are talking about open sourcing something, that's really the big argument against.

Re:CLA (1)

kthreadd (1558445) | about a month ago | (#47664753)

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.

Re:CLA (1)

ron_ivi (607351) | about a month ago | (#47664963)

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)

Re:CLA (1)

ron_ivi (607351) | about a month ago | (#47664803)

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?

Re:CLA (1)

Junta (36770) | about a month ago | (#47664955)

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 style license is acceptable because the risk is not the project owners. The statement is certainly not sufficient to be confident that something isn't wrong, but it's a stronger basis to pass on some culpability to the contributor in the event of issues.

The sort of CLA you are talking about are the ones with copyright assignment. The most prominent example of this is actually the FSF requiring copyright assignment of any accepted contribution. These can be employed when a company or organization wants to reserve the right to modify licensing. In the FSF case, this is why they can change license terms from GPL2 to GPL3, where in a project like the kernel, they cannot change the license because there are too many copyright holders. I actually don't know of a corporate sponsored CLA involving copyright assignment.

I had previously assumed CLA implied copyright assignment until I was forced to actually cope with a couple of CLAs and looked more carefully.

Re:CLA (1)

ciascu (1345429) | about a month ago | (#47666509)

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 of months of funded work? They want additional protection, you say? Then, by definition, we must be losing it. Anyway, it's easier to veto and ignore upstream submission - this is not our problem, our project's fine."

Signing over to the FSF may be fairly benign, but when you are talking about signing a document for a random upstream company, a CLA can be much more reasonable to explain.

Thorough blog article from Michael Meeks (of GNOME and other things) - https://people.gnome.org/~mich... [gnome.org]

The product owner and legal review? (0)

Anonymous Coward | about a month ago | (#47664343)

"Historically at my engineering firm .. the product owner and legal perform a deep review of the release .. How can we ensure we're not exposing ourselves or diluting our IP"

Fire all your IP lawyers and hire on more developers, else stop trying to FUD Github ..

Re:The product owner and legal review? (0)

Anonymous Coward | about a month ago | (#47664585)

Not sure why this is considered FUD. The thing about any DVCS is that once it is in the repo it stays in the repo. You have to be very careful about what is put out there in public. Given that this is git, though, I am not sure why the company does not use two repos. A private one for internal development, and a public one which has the merges from the private repo once a point in the graph clears any potential legal issues. This feature is one of the great strengths about git and github.

Re:The product owner and legal review? (1)

kthreadd (1558445) | about a month ago | (#47664781)

Not sure why this is considered FUD. The thing about any DVCS is that once it is in the repo it stays in the repo.

That's true for non-DVCS too. If it's out, it's out. Doesn't matter if you distributed tarballs or Visual SourceSafe. If it's out, it out.

You have to be very careful about what is put out there in public. Given that this is git, though, I am not sure why the company does not use two repos. A private one for internal development, and a public one which has the merges from the private repo once a point in the graph clears any potential legal issues. This feature is one of the great strengths about git and github.

Well, it's going to have a social impact. There won't be much collaboration when all the company does publicly is basically code dumps.

CYA (2)

halivar (535827) | about a month ago | (#47664355)

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.

Just do it all open from the start (1)

jwthompson2 (749521) | about a month ago | (#47664381)

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 on the project and one manager signing off on doing it this way. We're not a huge company, but we're a couple hundred employees strong and the development team basically makes the call, since they are the experts.

Better ways to do it. (0)

NemoinSpace (1118137) | about a month ago | (#47664391)

First let me say, there is nothing wrong with open source. But if you and your business associates are intent on giving stuff away for free, there's no reason to hang yourself with the GPL. Just bring your code and operations manual to the next convention and leave them on the table. At least your competitors might buy the drinks later.

Re:Better ways to do it. (1)

Anonymous Coward | about a month ago | (#47664621)

First let me say, there is nothing wrong with open source. But if you and your business associates are intent on giving stuff away for free, there's no reason to hang yourself with the GPL. Just bring your code and operations manual to the next convention and leave them on the table. At least your competitors might buy the drinks later.

Most code that is written isn't the kind that anyone's going to start selling for money. "Giving it away for free" can be better done as "handing on the code to a project which may actualy maintain it". That's actually a major benefit for the company which starts the work. Competitors getting the code is only a problem if they can find a way to add value to it whilst locking it away from us thus using it to get a competitive advantage. The actual biggest risk is that people think we will close the code later and so ignore it. This leads to some rules.

  • wherever possible try to contribute to an existing project
  • make sure your licensing and contributors agreements are fair (proper FOSS; no suspicious special case for the originator)
  • go with the most protective license available; you can always release more openly later but you cannot take back what's out there
  • reuse as much external FOSS code as possible;

The license thing is really important. There are many number of BSD / Apache idealogues out there who will tell you their license is more "free". There are others who will tell you that the GPLv2 is the only way. Ignore these people. Think about how to achieve your aim. If you are trying to get as many people as possible to use your file format, make the code for reading it public domain or as MIT licensed. If you want to get a community that will contribute back, aim for AGPLv3 which will stop competitors from hoarding changes.

Re:Better ways to do it. (0)

Anonymous Coward | about a month ago | (#47664629)

If the pieces of code are somewhat useful you can get some "free" bug fixes and lots of free testing by going open source. There is also some marketing/name recognition benefits, but not everyone can grasp those kinds of benefits.

Re:Better ways to do it. (1)

Junta (36770) | about a month ago | (#47665071)

If you do use the GPL *and* have copyright assignment, there actually could be a case made that you dual license it: GPL for those that play open source and proprietary commercial for others. This is the 'get free coders to do work for you' business model that seems pretty disingenuous, but at least there is a logic to a corporate sponsored project going for GPL.

What surprises me is that most scenarios where corporations pick the license, they pick a BSD style license. I can understand them wanting that property in *other* people's code, but surprise they wouldn't want more assurance that their work wouldn't come back to compete with them in a commercial way when they have a choice.

Re:Better ways to do it. (1)

bhlowe (1803290) | about a month ago | (#47667429)

Quite simple. BSD avoids legal problems that releasing code under GPL might create in the future. Plus, most (proprietary) software companies prefer BSD and altogether avoid GPL. So if a corporation is going to "give back" to the open source community, they'll do it under a license they most agree with. Anyone open sourcing code will want to do so with an eye towards future uses and whether it will be good or bad if used by a competitor.

Re:Better ways to do it. (0)

Anonymous Coward | about a month ago | (#47673355)

What legal problems can GPL create for the copyright holder?

Compartmentalize (0)

Anonymous Coward | about a month ago | (#47664405)

The only way around a review process is to keep the development work walled off from production entirely. That way there's no risk of cross-contamination and you'll only have to do reviews when bringing stuff in, and not pushing it out.

Move into the Future (2)

bill_mcgonigle (4333) | about a month ago | (#47664469)

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.

Move into the Future (0)

Anonymous Coward | about a month ago | (#47664829)

Exceptions don't prove the rule, the probe the rule. Having an exception proving the rule doesn't make any sense at all.

Rule-proving (0)

Anonymous Coward | about a month ago | (#47667389)

You are technically incorrect; the worst kind of incorrectness.

The distinction between the two words is far more recent than the phrase in question. Both words are very nearly identical in the current lexicon, and both share the same origin, the latin probare. The phrase itself derives from Roman jurisprudence, in full: exceptio probat regulam in casibus non exceptis, “the exception proves the rule [exists] in cases not excepted.” For example, if I told you that British naval officers were privileged to drink the King's health while seated, you would be able to infer from the exceptional case that the general rule is to drink the King's health while standing.

It's difficult to enumerate the various senses in which you are wrong: it's almost an achievement in itself.

Re:Move into the Future (2)

mi (197448) | about a month ago | (#47664839)

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 happening before "intellectual property" was invented — unless they had other sources of income, poets and writers (creators of easily copiable wares) were starving. Inventors, likewise, either went unrewarded for their inventions or were forced to monetize it themselves — and rare is a human, who is both a good inventor and a good businessman. As usual, leftists proclamations are dragging humanity into the past in the guise of "progress"...

artificial scarcity

There is no such thing.

This is the term Marxists use to justify spreading other people's wealth around, that's all. Oh, sure, music and movies can be copied indefinitely and designs and algorithms can be used by anyone once created. But all of those creators need very material things to sustain themselves — and neither food, nor shelter, nor (gasp!) healthcare can be copied via torrent.

Some companies are willing to release software to the wild, others do not. Basing one's employment decisions on that is, indeed quixotic.

Re:Move into the Future (0)

Anonymous Coward | about a month ago | (#47668553)

The real irony is in this insistence that companies make their products open source and that innovators release their patents but why? So other people can copy them!

Patents exist to allow the inventor to profit from their investment (time, money or both), while they have been misused the basic principle is sound. The advocates for openness have the tools to protect their inventions (copy-left and even royalty-free patents) in order to innovate however instead they spend their days trying to sell their open promise to the world but it appears the Emperor has no clothes. The openness advocates want to copy, not innovate. They are already free to innovate but where is the innovation?

Open Source wasn't late/non-existent in PCs, tablets, smartphones, DVRs, etc .. because of patents and copyrights, it was a lack of vision and lack of innovation. Corporations spend billions of dollars on research and development building these new products and the openness advocates then just want the freedom to copy them.

The Linux kernel and the Apache webserver are great examples of openness producing exceptional products and they didnt need corporations to subscribe to the open/free ideology to do it you only need that if you arent capable of innovating on your own. So show us the open dream is worth pursuing by innovating instead of begging for the ability to clone.

Re:Move into the Future (1)

Kjella (173770) | about a month ago | (#47664921)

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.

Re:Move into the Future (1)

westlake (615356) | about a month ago | (#47666029)

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.

Open Source really requires a Community, not just (0)

Anonymous Coward | about a month ago | (#47664471)

If you just barf your code on the internet, it feels like you are just asking the rest of the world to take it over for you. Building publicly from the start (or very early) allows you to build such a community, which will give you a much better chance that the code will survive outside just your team working on it and continuing to dump more code online.

Considering the number of IP trolls... (0)

Anonymous Coward | about a month ago | (#47664477)

like Exago (http://www.exagoinc.com/) that will try to extort money from you if they catch you open sourcing software, we simply stopped doing it. It's just too risky.

In Exago's case, they claimed that because we were graphing SNMP data that we had to pay them money. Unfortunately they got my home number and would call me at 4am each night. They are simply toxic.

If it's OSS, it's not your IP (0)

Anonymous Coward | about a month ago | (#47664527)

Just sayin'

Waaaay too general. (3, Insightful)

Vellmont (569020) | about a month ago | (#47664547)

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.

Incentive? (0)

Anonymous Coward | about a month ago | (#47664557)

What incentive does the typical company have to make their software open source?

Use github forks (1)

Anonymous Coward | about a month ago | (#47664577)

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.

Rust (2)

PCM2 (4486) | about a month ago | (#47664645)

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 (0)

Anonymous Coward | about a month ago | (#47664895)

It's also very hard to get unaffiliated developers when the overwhelming meme amongst open-source projects is that it's about developers, not users.

Re:Rust (3, Insightful)

Junta (36770) | about a month ago | (#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.

contact a few likely users. Use forums (1)

raymorris (2726007) | about a month ago | (#47667677)

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 organizations. Some modules are used by three to five organizations. If three other organizations are using it and helping with development, that's a lot of work I don't have to do.

Re:contact a few likely users. Use forums (0)

Anonymous Coward | about a month ago | (#47670473)

What is your job, who do you work for, and what does said company do raymorris?

Re:contact a few likely users. Use forums (1)

dasacc22 (1830082) | about a month ago | (#47671385)

Good fucking god, who gives a shit where he works. How fucking long are you going to make an ass of yourself under this ray's posts. Guess what?! I don't use a hosts file! But why you ask?! Its fast! Its secure! Its reliable! Because I use my hosts file for other things unrelated to advertisement and don't need it littered with a bunch of bullshit. Some people do things different, now move along.

Re:contact a few likely users. Use forums (0)

Anonymous Coward | about a month ago | (#47682629)

dasacc22 = raymorris sockpuppet obviously and a typical tactic from advertisers.

raymorris made an ass out of himself (0)

Anonymous Coward | about a month ago | (#47692987)

That's proven literally a 100++ times in this exchange http://it.slashdot.org/comment... [slashdot.org]

Sergey Aleynikov (1)

vossman77 (300689) | about a month ago | (#47664657)

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

Its better to contribute to an existing project... (1)

jjn1056 (85209) | about a month ago | (#47664671)

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 contrib to an existing project rather than release some vanity ware and try to pretend the company is all hip and cool because you have a github account.

Its also a good way to get around the legal review and all, since generally if you are just sending patches to an existing project, typically bug fixes and feature enhancements there's not a big need for it. I think its easier for rusty management to accept you contributing documention, test cases and bug fixes to an already existing project than to get them to allow you to take some big in house project and get it out in the open.

If you build your in house stuff around existing open source projects and really leverage open source at all points in the stack (from automation and up) you will find lots of good ways to contribute back to those projects and you will find your custom code is mostly glue and company 'secret sauce' that you'd never give away anyway.

Re:Its better to contribute to an existing project (1)

Trepidity (597) | about a month ago | (#47664867)

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.

And those are the better ones! The really bad open-source dumps don't even really build or work outside the original company's complex production environment, and don't have any documentation for how to set up such an environment.

Possibly dangerous (0)

Anonymous Coward | about a month ago | (#47664861)

Does your really have a strong incentive to go OSS? Open source does not automatically make everything better. Often it is like handing the knife to your competitors.

Are you promoting it at all? (1)

MillerHighLife21 (876240) | about a month ago | (#47664863)

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.

remove comments (1)

BradMajors (995624) | about a month ago | (#47665167)

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

My Corp (0)

Anonymous Coward | about a month ago | (#47665353)

My corp freaks out when I just want to use a library/piece of code I found on GitHub.

Before planting a seed, prepare the field (3, Insightful)

Michael Tiemann (3136525) | about a month ago | (#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.

IBM does it, quite a bit. (0)

Anonymous Coward | about a month ago | (#47665885)

(disclosure: I work for IBM, but these are MY comments, not theirs)

IBM has done a lot in this area, and they even have publicly posted documents around subjects like these. (See http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101260 or http://www-03.ibm.com/linux/ossstds/ for examples.)

They do have a lot of legal reviews around the use and even viewing of code, so it is not something taken lightly.

It can be a legal mine field, but it can also be a beautifully rich and prosperous garden.

No, only need more women policy (0)

Anonymous Coward | about a month ago | (#47668775)

No, what only need is more women policy.

Engage with your community earlier (1)

fpodoo (3785109) | about a month ago | (#47671073)

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 something that has been developed for your own need rarely fit others needs (in terms of quality, feature, collaborative platform, ...).

If you think about it in terms of collaboration (working on github since the beginning, blogging about what you do, answer on issues, tweets, ...) you can get benefit from your open source contributions. Those benefit are mostly about small contributions (bug reports, translations, new features) or visibility. The key is to make it easy to on board new users/developers: work on the platform they already use (github), use transifex for translations, ...

I think it's a bad idea to start your repository private at the beginning. People are always afraid to "show to the world" an unfinished development but it's not a real issue if you are transparent about the status of the project. If you want people to feel engaged in your project, you have to on board them since the beginning. And contributions are more valuable if they come earlier in the development process. We noticed we get a much better engagement with our communities when we engage them in the very early stage of the project, at the analysis phase.

Protecting your IP is quite easy: choose the right licence and set a Contributor License Agreement. Merge Pull Requests only if they agreed on your CLA.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>