Download presentation
Presentation is loading. Please wait.
Published byDenis Dawson Modified over 8 years ago
1
The Insight Toolkit Case Study Dr. Luis Ibanez, Kitware http://creativecommons.org/licenses/by/3.0 /
2
2 © 2007 Luis Ibanez ● This presentation is Copyrighted by Luis Ibanez ● This presentation is distributed under the Creative Commons Attribution License 3.0: http://creativecommons.org/licenses/by/3.0/ http://creativecommons.org/licenses/by/3.0/ ● You are free to Reuse ● You are free to Remix ● Provided that you give credit to the author
3
3 This presentation was created using Open Source Software Open Office copyright is jointly held by Sun Microsystems and Contributors. The software is distributed under the GNU Lesser General Public License Version 2.1.
4
ITK Sponsors The National Science Foundation The National Institute for Dental and Craniofacial Research The National Institute of Neurological Disorders and Stroke
5
ITK Developers
6
* indicates a subcontractor. ITK Developers
7
Public Investment $13 Million March 2000 First code check-in 2,040 # of nightly builds 1,289 tests run nightly 42 # of platforms ( software + hardware ) 1,647 # of C++ classes 2,314 # of files with code ( Insight / Code directory ) ITK by the Numbers
8
136K # of lines of code ( Insight / Code directory) 102K # of lines of test code ( Insight / Testing directory) 81.6% Code coverage (gcov) 27K # of lines of examples ( Insight / Examples directory) 114K # of lines of Applications (InsightApplications checkout) 328 weekly t-cons 82 unique developers ITK by the Numbers
9
1,380 # of users subscribed to the mailing-list 345 # of monthly emails in users-list (Oct’06 - Sep’07 average) 836 # of pages in the Software Guide PDF document 15,040 # of Software Guide PDF downloads (sourceforge) 3,393 # of monthly hits to the URL of the ITK Software Guide 4,169 # of Insight Applications downloads ITK 3.4 (sourceforge) 8,659 # of source code downloads ITK 3.4 (sourceforge) ITK by the Numbers
10
10 Growth http://www.ohloh.net/projects/3240/analyses/lates t
11
11 Ohlo Statistics** http://www.itk.org/HTML/Statistics.ht m
12
12 Design Decisions ● Data Pipeline ● Large Datasets ● N-D Images ● No Visualization (importance of “scoping”) ● No GUI (scoping) ● Image Segmentation ● Image Registration
13
13 Implementation Decisions ● C++ Templates ● Wrapping ( Tcl, Python, Java ) ● Multi-platform – Windows, Linux, Sun, SGI, Mac* ● Image Iterators ● Readers (many formats) ● 32 bits / 64 bits
14
14 Software Process ● CVS Repository ● Dashboard – (Nightly, Continuous, Experimental) – Code Coverage – Dynamic Analysis ● Doxygen Documentation
15
15 Release Early, Release Often ● Beta 1.0: 2002 Feb ● Beta 2.0: 2002 Jun ● ITK 1.0:2002 Oct ● ITK 1.2:2003 Mar ● ITK 1.4:2003 Sep ● ITK 1.6:2004 Jan ● ITK 1.8:2004 Aug ● ITK 1.8.1:2004 Sep ● ITK 2.0:2005 Feb ● ITK 2.0.1:2005 Mar ● ITK 2.2:2005 Aug ● ITK 2.4:2005 Nov ● ITK 2.6:2006 Mar ● ITK 2.8:2006 Jun ● ITK 3.0:2006 Nov ● ITK 3.0.1:2007 Jan
16
16 Release Early, Release Often ● ITK 3.2:2007 Mar ● ITK 3.4:2007 Sep ● ITK 3.6:2008 Apr** ● ITK 3.8:2008 Jul ● ITK 3.10:2008 Oct*
17
17 Project Spin-offs ● CMake (multi-platform support) ● CableSwig (wrapping C++ templates) ● GCC-XML (wrapping C++ templates)
18
18 Backward Compatibility ● Version (N) should work as version (N-1) ● Promise to users – Key to adoption and retention ● The meaning of Deprecation (discourage use) ● We don't know who our users are ● We don't know (for sure) how they use ITK ● Compatibility vs Progress – Agile methods: trial & error ● Providing backward bugs (e.g. Critical apps)
19
19 Coding Style ● Prepare for bloody violence ● The code should look like written by only ONE developer ● Must be checked automatically – KWStyle – CVS / SVN commit filters – Dashboard test (daily) ● Process must feed-back to developers ● Training / Learning process
20
20 Code Coverage ● If it is not tested: it is broken ● Start from day zero ● Error management challenge (many “if()s”) ● Exponentially harder (last %s) ● Should be tested automatically – gcov: line coverage – Bullseye: branching coverage
21
21 Dynamic Analysis ● Test from day Zero ● Valgrind ● Rational ● Most reports are Real errors ● Slower to run – In ITK it takes more than 24 hours – Rolling testing ¼ of the toolkit per day
22
22 Users Mailing List ● Main communication channel ● Important: Welcome beginners ● Appreciate feedback – Bug reports – Code contributions ● Cultivate helpers – Users who help other users ● Deal with demanding customers – Confused with customer support
23
23 Wiki ● Excellent tool – Middle way between Email & static HTML ● We adopted late ● Pressure from a user – “can do” type of user – Progress by public shame ● Requires maintenance (guidance)
24
24 Telephone Conference ● Coordination among developers ● Weekly ● When preparing releases ● Language barrier ● Cultural barrier ● Taking turns
25
25 Tutorials ● Online tutorials ● Conferences ● User-generated content ● Beginner vs Advanced ● Tutorials as a business model – Consulting – Training (e.g. Blender) – Popularity / Adoption / trade-offf
26
26 Documentation
27
27 Documentation ● Document as you go ● Doxygen – Comments along with the code ● Examples role ● Documentation maintenance – Many eyes... ● Code reviews
28
28 Manuals ● Documentation – Free / Sold ● Apply Open Source methods to manuals (e.g. Incorporate users corrections) ● Teach by example ● Maintaining (updates)
29
29 Copyright and License ● Defined before day 1 ● License – Clear – Stable ● One change in 8 years ● Proper advertisement ● Beware of contributions – Remove infringements immediately
30
30 Governance ● Meritocracy ● Those who write the code make decisions – (most of the time...) ● Reaching consensus ● Accepting contributions
31
31 End
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.