Guidelines for Open Sourcing Code? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 7 years ago.

Improve this question

Step 1: Convince the president of my vertical to consider open sourcing a body of code

Step 2: ???

To give a bit more detail, I've already successfully convinced my boss and boss's boss to consider open sourcing a body of code that was written mainly as a demo platform for our company. We've already determined that the code is useful and understand the benefits to open sourcing the code.

Now the question is where to go from here? What are the next steps? The president said that he'd like to see a project management proposal which would contain details like:

• Who would manage changes to the code?
• What would the process lo开发者_C百科ok like to release new code?
• How is the code review process defined before releasing code?
• Who will participate?
• What are the legal aspects that need to be considered first?

What I think I need is a "Open Sourcing Code for Dummies" guide or if there are some simple guidelines, how-to's, or templates for putting together a proposal available. I'd like to hit a home run on my first at bat and plop a solid proposal in his inbox. Any advice, resources, or ideas on how to structure such a proposal would be helpful.

---

I would consider the following:

• Think clearly about the goals of open-sourcing your software and check all your decisions in this light.
• Double check, if all licences of used libraries are compatible with the chosen license and you have the permission to use anything in the codebase. This also includes images or other non-code. If the source is world-visible, copyright-infringements are easy to spot, and your competitors might use the chance to make you trouble.
• Choose an appropriate license. Most important decision might be copyleft (GPL, AGPL) or not (Apache, BSD, MIT).
• Check your code again and remove anything, that you don't want to see in the public (silly comments or so).
• Write a documentation to build the software from the source. If you have a good buildfile that could be as easy as 'make', but most likely you have to document about dependencies like installed libraries and so on.
• Provide some way to contact your company about the software. maybe an e-mail-address and a someone, who answers to this e-mail.
• If you want to attract external coders, document some important parts of the sourcecode. Provide some basic documentation about the structure, that external developers can figure out, which source-file they should edit, to change behaviour X of the software.
• If you want to work with external programmers, you will need an world-readable Version-control. If you get patches, that are outdated against your actual codebase, it isn't helpful. If you have persons, who often send patches, give them commit-rights. Also an open bug-tracker is useful. If you don't want to host the two tools yourself at your company, use an Open-Source Hosting site.
• If you choose a copyleft-license, let all external committers sign a contract, that give you permission to use their additions. Otherwise you couldn't use the changes in other propietary products of your company.

That's it, what comes to my mind at the moment.