Instance action: 10 Steps to teach you to convert closed source items to open source

Difio is a Django based application that tracks your package and notifies you when it changes. It provides a variety of variations, so you can determine when and how you want to upgrade in time. Previously, Difio was a closed source project, but the authors decided to open it up to be able to deploy internally and attract more community developers. The following is the author Alexander Todorov wrote the Difio open source process experienced 10 steps, compiling the main contents as follows, for your reference.

1. Delete unnecessary code

Any project that has existed for several years will accumulate code and functionality that is no longer in use. Delete all the code that can be deleted to keep the project simple. Open source Difio about 20% of the existing code was deleted before, including:

Unused and obsolete settings

Django Applications

static files and templates

Model Class (Class)

Old URL

Deprecated features

Other Python tools

Delete content and one-time code that requires additional management. For example, I used markdown in some templates and used pure HTML in other places, and some template tags were only used in one or two places. Remove all of these to ensure a more consistent template. Hard-coded paths, values, URLs, etc. are unavoidable in rapid prototyping. Sometimes, an application that closes the source code and a legacy of its deployment environment needs to be cleaned up. I've set up and used custom template labels where I need them.

2. Create separate modules

Re-organizing the document structure also makes everything simpler and more natural. Let the modules be independent and self-contained so that it is easier to separate later.

The DIFIO Web backend is deployed in OpenShift, which uses different directory layout templates and static files. I moved the files and updated the Django settings so that they were loaded correctly, which also allowed me to rethink the way static source files were delivered to the CDN backend.

3. Separating internal and external code

It is normal to have some internal code in your application to provide you with more information. These code such as usage tracking, other metrics, billing information, etc. In the case of web-based services, these functions are usually integrated with the http://www.aliyun.com/zixun/aggregation/17626.html "> core functions, but they need to be separated."

It's also a good chance to decide what to leave behind. For example, Difio does not have a test case that transmits it, because separating them from the CI environment requires a lot of work.

DIFIO contains five separate modules:

difio/(core user experience)

A configuration file Subsystem

Billing Module

Extension Management Module

Deployment-related modules (mainly settings)

All of these are properly decoupled and isolated to eliminate internal dependencies. Currently difio/relies on several configuration file APIs that provide normal defaults, and this step also helps you detach some work from the core user experience (such as custom email templates).

4. Code Refactoring

Refactoring and testing should be an ongoing process. However, you may have done a quick review of all the existing code so far and found that many things need to be improved. This is also a good opportunity to create a short roadmap and revise your feedback (ISSUE) tracking system. It can help with your new project presentation and continuous improvement early on.

On the Difio project, I mainly reconstructed some internal methods to adapt to the new application architecture. External methods are left to be resolved later, as they are not required.

5. Do a good job in legal affairs

Depending on the complexity of the software and the size of the organization, migrating to open source may be time-consuming, from choosing the right license, branding, author naming, legal review, searching for potential tort code, etc.

This is much simpler for Difio. I chose the Apache 2.0 protocol, added protocol instructions at the beginning of all source files, and handled the rights and copyrights of the external code I could find on the Internet.

6. Update and List of external resources

As a software developer, you must upgrade the referenced external software to the latest version in a timely manner and ensure that the software is working properly. No one wants to run old external programs, and old external programs sometimes don't work. You also need to provide a list to let others know how to run and install the software.

Fortunately, there are only a limited number of problems and programs in Difio that rely on external projects.

7. Providing documentation and samples

For each new person who wants to join your project, the document is very important. After all, your open source is a desire to get everyone involved, and written documents and examples are necessary.

For Difio, I wrote a detailed readme file because the program has multiple subsystems (messaging, cron calls, etc.), and it has a lot of configuration. The second document I created is a content management guide because there are things that need to be manually adjusted, and these two files encompass the most important design and deployment features of Difio. However, you may need to write more documentation for your project.

8. Create a common code base

You need to create a common code bin and push the software code up.

For Difio, I decided to copy the contents of the entire difio/directory and initiate the submission. The previous history has not been used, but I still decided to do so to avoid leaking some of the keys and passwords in the hard code. In real-world development, because of my cloud environment using GIT deployments, git sub modules replaced the difio/directory, which shortened the release/deployment cycle.

From now on, everything you've done with the source code should be done openly.

9. Independently deploy a new test environment

Until recently, you might have been working on a local copy of a particular version of the application, such as inheritance, environment, and so on, but testing from an external user's perspective in a new environment will help you refine your documentation and clean up your legacy issues.

When I tested Difio, I found several missing or excessive requirements, missing or inappropriate settings, errors, and incomplete documents.

You need to constantly modify, test, until each step is reasonable, out-of-the-box, which will ensure that your users and future contributors can successfully install your software.

10. External declaration

This is the last step! Write an article that announces your software's open source information.

Congratulations to you! Now you have completed the conversion from closed source to open source!

Original link: http://code.csdn.net/news/2819666