[IGSTK-Developers] Patrick's summary from SPIE demo

[Kevin Cleary]

Hi everyone:

 

Greetings from Kauai, Hawaii, where the weather finally was nice this
afternoon after several days of rain! But I am sure you don't want to hear
that ;)

 

Patrick gave me a very nice writeup on the SPIE demo that I want to share
with everyone

 

He correctly notes that unless we develop a user community the toolkit will
not catch on 

 

So I encourage everyone to read his thoughts below and perhaps we can just
spend a few minutes on the tcon tomorrow discussing this

 

There will also be a bonus for anyone who knows what the word "promethean"
is as Patrick used it below - I had to look it up myself!

 

Kevin

The IGSTK demo for SPIE went on pretty well and we had a good crowd of
audience, around 50~60 people. I guess half of the people are Kevin's
collaborators, sponsors, and supporters, and the other half are people who
are really interested in this toolkit. So we still have our market out
there. 

I have got plenty of positive feedbacks from both the demo and poster
session. I summarize them into following categories: 

1.	IGSTK really scratches the itches for the image guidance research
community. Most of the people told me this is the toolkits they wanted and
waited for so long. Some one even told me he wants to build the same thing
as the demo application and uses it in his proposal. So there is a demand
for IGSTK here, the question is will us be able to meet the user's
requirements and expectations? 
2.	IGSTK has some promethean ideas. Some people were interested in the
state machine and logging components in IGSTK, and they want to incorporate
those into their own development. There is a possible opportunity to promote
the design pattern of IGSTK as an open standard for surgery guidance
applications. 
3.	One big concern is: Is IGSTK easy to use? Will it help with my
research? I think we are somewhat blind while pursuing the technical
innovation and being paranoid for safety. We ignored the users for a long
time. In fact an open source project should be user driven at the very
beginning, but it's not too late for us to think about how to attract users
now. We can do the following to increase the usability and marketability of
IGSTK: 

1.	Provide elaborate documentation and API reference 
2.	Write "The Book" to justify our design choice (another way to
promote open standard) and give out nice user tutorial. 
3.	Provide convenient script or automatic process to build and use the
toolkit. Provide template application to give user a jump start. 
4.	Make more example and ready to use applications 
There are more we can do: 
5.	Give options to user to build IGSTK in different critical level.
Lower critical level will have less API restriction and more flexible. 
6.	Make IGSTK usable for people who are only interested in IGSTK's
components such as the tracker, state machine, logger, and so on. 
7.	Support different GUI, and extend IGSTK based on user requirements.
While talking to people in the conference, I encouraged them to try it, give
us feedbacks, and submit feature requirements. Reason one is to get user
involved in the future development, reason two is to keep IGSTK moving
forward. 

For the future: 

1.	To make IGSTK a success open source project, our key task in the
remaining phase of this project is to promote IGSTK and build user
community. We can't just make this toolkit and give it out for free. We have
to make sure it is a good toolkit that people are willing to use it, and
keep developing it. 
2.	One possible source of funding would be: If we have a good number of
users and make IGSTK the leading toolkits in this field, we can then seek
for industry support from hardware maker such as NDI. This is the "Widget
Frosting" business model mentioned in Eric Raymond's paper,
<http://www.catb.org/%7Eesr/writings/magic-cauldron> "The Magic Cauldron"
(http://www.catb.org/~esr/writings/magic-cauldron). For spending very little
on supporting the open source development of IGSTK, the hardware company can
actually get more returns. Quote, "In this situation, opening source is a
no-brainer. There's no revenue stream to lose, so there's no downside. What
the vendor gains is a dramatically larger developer pool, more rapid and
flexible response to customer needs, and better reliability through peer
review. It gets ports to other environments for free. It probably also gains
increased customer loyalty as its customers' technical staffs put increasing
amounts of time into the code to improve the source as they require." This
is all based on the popularity of our toolkit, so we should keep promoting
and improving our toolkit. 

 

 

  

------------------------------------------------------------------
Kevin Cleary, Ph.D.                        Work phone: 202-687-8253
Associate Professor                        Work fax: 202-784-3479
Deputy Director  
                            
Imaging Science and Information Systems (ISIS) Center
Department of Radiology                    Pager: 202-901-2033
Georgetown University Medical Center       Cell phone: 202-294-3409
2115 Wisconsin Avenue, Suite 603           Home phone: 301-299-0788
Washington, DC, 20007                      Home fax: 301-299-0789

 

ISIS center:  <http://www.isis.georgetown.edu/> www.isis.georgetown.edu
Research group:  <http://www.caimr.georgetown.edu/> www.caimr.georgetown.edu
WashCAS:  <http://www.washcas.org/> www.washcas.org
Email:  <mailto:cleary at georgetown.edu> cleary at georgetown.edu
-------------------------------------------------------------------

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20060223/b774c46f/attachment-0002.html>