The project basically dates back to 1995. When a maintainer left then somebody else always took over. I think this would be even more true today because of several reasons. This is how open source works.
But there's more to a stable project than a lot of enthusiastic contributors.
Some developers are paid to work on the project.
There has to be a central gatekeeper who provides project management, makes sure code gets reviewed, and imposes some kind of vision on the disparate goals of the contributors. I assume you have somebody like that,
Yep, that's supposed to be me;-) Code review is not enough, test cases are also required for new code and bug fixes, moreover no regression is allowed in our test suites: http://ntfs-3g.org/quality.html
The roadmap is user feedback, developer contribution and sponsor-driven. The main priorities are reliability/stability, most requested features, and performance.
NTFS-3G doesn't cache anything yet but it always recompute the info. The kernel already does the caching (data, file attributes,...) which is currently partly turned off by NTFS-3G to provide full POSIX semantics for hard links needed by some backup tools.
First comes reliability and POSIX correctness then performance where we are getting soon (btw, I'm the lead developer). The above is the main reason for the high CPU usage, basically this one from the page: "If NTFS-3G uses close to 100% CPU time then it's usually a driver issue, though not always." But this will significantly change in the future when the project priorities allows it.
Oh, and there's also NTFS-3G, backed by some Russian guy.
The most active current NTFS-3G developers are Hungarians, Finnish, French, Swedish, Germans, Belgian and Argentine. Though anybody would be certainly very welcome, independently of nationality. Significant past contributor Yura Pakhuchiy is Belarusian and Anton Altaparmakov was born in Bulgaria.
Sponsors of the project are from all over the world, mostly from the USA.
In practice, we don't see significant performance hit in daily use because of the NTFS-3G driver architecture. All known performance problems are due to other reasons which are being already addressed.
In fact, the performance results of the hybrid space, unoptimized NTFS-3G driver is already comparable or sometimes even better than the results of several in-kernel file system drivers. If you're interested, there are some technical explanation on the kernel list at http://lkml.org/lkml/2008/4/18/136
Reasons for the most common NTFS-3G performance problems, which are often incorrectly attributed to its hybrid space nature, can be found at http://ntfs-3g.org/support.html#slow
Slashdot Mirror
Yes, the development work is sponsored long term.
The project basically dates back to 1995. When a maintainer left then somebody else always took over. I think this would be even more true today because of several reasons. This is how open source works.
But there's more to a stable project than a lot of enthusiastic contributors.
;-) Code review is not enough, test cases are also required for new code and bug fixes, moreover no regression is allowed in our test suites: http://ntfs-3g.org/quality.html
Some developers are paid to work on the project.
There has to be a central gatekeeper who provides project management, makes sure code gets reviewed, and imposes some kind of vision on the disparate goals of the contributors. I assume you have somebody like that,
Yep, that's supposed to be me
The roadmap is user feedback, developer contribution and sponsor-driven. The main priorities are reliability/stability, most requested features, and performance.
NTFS-3G doesn't cache anything yet but it always recompute the info. The kernel already does the caching (data, file attributes, ...) which is currently partly turned off by NTFS-3G to provide full POSIX semantics for hard links needed by some backup tools.
First comes reliability and POSIX correctness then performance where we are getting soon (btw, I'm the lead developer). The above is the main reason for the high CPU usage, basically this one from the page: "If NTFS-3G uses close to 100% CPU time then it's usually a driver issue, though not always." But this will significantly change in the future when the project priorities allows it.
Oh, and there's also NTFS-3G, backed by some Russian guy.
The most active current NTFS-3G developers are Hungarians, Finnish, French, Swedish, Germans, Belgian and Argentine. Though anybody would be certainly very welcome, independently of nationality. Significant past contributor Yura Pakhuchiy is Belarusian and Anton Altaparmakov was born in Bulgaria.
Sponsors of the project are from all over the world, mostly from the USA.
In practice, we don't see significant performance hit in daily use because of the NTFS-3G driver architecture. All known performance problems are due to other reasons which are being already addressed.
In fact, the performance results of the hybrid space, unoptimized NTFS-3G driver is already comparable or sometimes even better than the results of several in-kernel file system drivers. If you're interested, there are some technical explanation on the kernel list at http://lkml.org/lkml/2008/4/18/136
Reasons for the most common NTFS-3G performance problems, which are often incorrectly attributed to its hybrid space nature, can be found at http://ntfs-3g.org/support.html#slow