Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×

Submission + - How do you assess the status of an open source project?

Chrisq writes: Our software landscape includes a number of open source components, and we currently assume that these components will follow the same life-cycle as commercial products, they will have a beta or test phase, a supported phase, and finally reach the end of life. In fact a clear statement that support is ended is unusual. The statement by Apache that Struts 1 has reached end of life is almost unique. What we usually find is:
  • Projects that appear are obviously inactive, having had no updates for years
  • Projects that obviously not going to be used in any new deployments because the standard language, library, or platform now has the capability built in
  • Projects that are rapidly losing developers to some more-trendy alternative project
  • Projects who's status is unclear, with some releases and statements in the forums that they are "definitely alive", but which seem to have lost direction or momentum.
  • Projects that have had no updates but are highly stable and do what is necessary, but are risky because they may not interoperate with future upgrades to other components.

By the treating Open Source in the same way as commercial software we only start registering risks when there is an official announcement. We have no metric we can use to accurately gauge the state of an Open Source component, but there are a number of components that we have a "bad feeling" about.

Are there any standard ways of assessing the status of an open source project? Do you use the same stages for Open source as commercial components? How do you incorporate these in a software landscape to indicate at-risk components and dependencies?

Submission + - How do you assess the status of an open source project?

Chrisq writes: Our software landscape includes a number of open source components, and we currently assume that these components will follow the same life-cycle as commercial products, they will have a beta or test phase, a supported phase, and finally reach the end of life. In fact a clear statement that support is ended is unusual. The statement by Apache that Struts 1 has reached end of life is almost unique. What we usually find is:
  • Projects that appear are obviously inactive, having had no updates for years
  • Projects that obviously not going to be used in any new deployments because the standard language, library, or platform now has the capability built in
  • Projects that are rapidly losing developers to some more-trendy alternative project
  • Projects who's status is unclear, with some releases and statements in the forums that they are "definitely alive", but which seem to have lost direction or momentum.
  • Projects that have had no updates but are highly stable and do what is necessary, but are risky because they may not interoperate with future upgrades to other components.

By the treating Open Source in the same way as commercial software we only start registering risks when there is an official announcement. We have no metric we can use to accurately gauge the state of an Open Source component, but there are a number of components that we have a "bad feeling" about.

Are there any standard ways of assessing the status of an open source project? Do you use the same stages for Open source as commercial components? How do you incorporate these in a software landscape to indicate at-risk components and dependencies?

Slashdot Top Deals

"Morality is one thing. Ratings are everything." - A Network 23 executive on "Max Headroom"

Working...