The UpgradeJS Blog

Whether you're joining a team to work on an existing application, or just want to get a better idea of the status of the application you've been working on for a while, static analysis tools can help.

These tools can provide you with a better sense of the size and scope of your application, its architecture, and provide insight into areas of importance, high complexity, low test coverage or poor testability, and more.

Of course, these tools are no substitute for human review and team discussion, but they certainly can be used to expedite that process.

Contributing to open source projects is a big part of our philosophy at OmbuLabs. It’s even written into our values. Some of us like to contribute to open source even in our spare time!

Recently we have been thinking about what guidelines we should follow when starting a new open source project, and also about how to organize and keep track of the ones we contribute to.

This article will give you some tips on keeping those open source projects organized, and also how to start them off on the right foot.

There are some really great guides for starting a new open source projects, yet when it comes to dealing with a possibly abandoned, unmaintained project, there is no definitive guide for users, contributors, or maintainers.

I hope that this can be a useful guide for our community.

Problem

When do you declare that an open source project has been abandoned? How many days have to go by until you start maintaining your own fork? What's the standard for communicating with maintainers, contributors, and users? How do you avoid n competing OSS forks of popular projects? How do you avoid duplicated work by people who want to maintain popular, but unmaintained OSS projects? What's the best way to find that one fork everybody is using?