SURVEY:SUMMARY:BUILD_DIFFICULTY[not_applicable, reasonable_effort, code_problematic or string] not_applicable
SURVEY:SUMMARY:CLASSIFICATION[practical,theoretical,hardware] practical
SURVEY:SUMMARY:CORRECT_CODE_LOCATION[string] by email
SURVEY:SUMMARY:PUBLISHED_CODE[not_applicable, yes, no] yes
SURVEY:SUMMARY:SAME_VERSION[not_applicable, yes, no_but_available, no_and_not_available] yes
SURVEY:SUMMARY:STUDY_FOUND_CORRECT_CODE[not_applicable, yes, no] no
SURVEY:AUTHOR1:BUILD_COMMENT[string] 
SURVEY:AUTHOR1:BUILD_DIFFICULTY[not_applicable, reasonable_effort, code_problematic or string] not_applicable
SURVEY:AUTHOR1:BUILD_DIFFICULTY_COMMENT[string] none
SURVEY:AUTHOR1:CLASSIFICATION[practical,theoretical,hardware] practical
SURVEY:AUTHOR1:CLASSIFICATION_COMMENT[string] 
SURVEY:AUTHOR1:CORRECT_CODE_LOCATION[string] by email
SURVEY:AUTHOR1:PUBLIC_COMMENT[string] Publishing or giving out code is easy. The hard part is to find enough resource to clean it up, make it portable, document it, and support it especially when the main goal of a project is not to build a widely used open source system but to demo ideas of a paper. Anyone with large system experience could imagine that there will be many system specfic hacks, shortcuts, and workarounds in the implementation of distributed system with many moving parts. For example, we may hard code a storage path or make some assumptions about access control configuration of the underlying systems. Such things will definitely not impact the  validity of our results. And they can be smoothed out from the system given enough engineering resouce. Before that happen, we had to do substantial support work to help people deploy and run our system in the past several cases.
SURVEY:AUTHOR1:PUBLISHED_CODE[not_applicable, yes, no] yes
SURVEY:AUTHOR1:SAME_VERSION[not_applicable, yes, no_but_available, no_and_not_available] yes
SURVEY:AUTHOR1:SAME_VERSION_COMMENT[string] 
SURVEY:AUTHOR1:STUDY_FOUND_CORRECT_CODE[not_applicable, yes, no] no