தொடங்குதல்
The Cathedral and theBazaar
என்ற தலைப்பில் Eric Raymond எப்படி இலவச மென்பொருள் திட்டங்கள்
உருவாகின்றன என்பதன் உன்னதமான மாதிரியை வழங்கியுள்ளார். அவர் குறிப்பிட்டு உள்ளது:
அனைத்து சிறந்த மென்பொருள்களும் உருவாக்குபவரின் தனிப்பட்ட
தேவையை ஈடு செய்ய இயலாமல் ஏற்பட்ட அலுத்தத்தால் உருவானவையே.
(from catb.org/~esr/writings/cathedral-bazaar/
)
ரேமண்ட் தனிப்பட்ட தேவையால் மட்டும்தான் திறந்த மூல திட்டங்கள் உருவாகின்றன என
கூராவில்லை. மாராக, அவர் சிறந்த மென்பொருள்கள் உருவாவது
உருவாக்குபவர் அந்தகைய தேவையை தானாக முன்வந்து தீர்த்து கொள்ள முயலும் பொது தான் என்கிறார்;
திறந்த மூல திட்டங்களுக்கும் இத்தகைய தனிப்பட்ட தேவைகளுக்கும் உள்ள சம்பந்தம் என்னவென்றால்
இத்தகைய அதிமுக்கிய காரணமாக இருப்பது மட்டுமே.
இவ்வருதான் பெரும்பாலான திட்டங்கள் தொட்ங் பட்டன தற்க்காலத்தை விட; இதை ரேமண்ட்
எழுதிய 1997 களில் மிக அதிக விழுக்காட்டில் உருவாகின. இன்று பெரும்பாலும் நிருவனக்களால்
—அரசாங்கங்கள், லாப நோக்கற்ற நிருவனங்கள், லாப நோக்கம் உடைய நிருவனங்கள்—
அடிப்படையில் இருந்து மத்திய கட்டுப்பாட்டுடன் மருவுருவாக்கம் சேய்ய படும் திட்டங்கள் தான் அதிகம்
தோன்று கின்றன. தனிப்பட்ட தேவையால் ஆற்வமுற்று அதை சார்ந்த மற்ற சிக்கல் கலுக்கும் தீர்வுகாணம்
திட்டங்கள் இன்றும் சிரப்பான மென்பொருள்களை உருவாக்கினாலும் அது மட்டும் இருதியான ஒரே
காரண்ம் அல்ல.
எனினும் ரேமண்ட் குறிப்பு இன்னும் உள்ளார்ந்து. திர்ந்த மென்பொருளின் வெற்றிக்கு
அத்தியாவசிய தேவை மென்பொருள் உருவாக்குபவர்களின் அக்கறை, வழக்கமாக அவரகள் தங்கள்
சுய பயன்பாட்டிற்கு அல்லது பயன்படுத்தும் தேவை உள்ளவர்களுடன் நேரடியாக வேலை செய்வதால்
அதில் ஈடு கின்றனர். அது அவர்கள் செய்ய நினைப்தை செய்படுத்தவில்லை எனில் அந்த தனி
நபரோ அல்லது நிவனமோ அதிருப்தி அடைவர். உதாரனமாக Kauli அறக்கட்டளையால்
(kuali.org), உருவாக்க பட்ட
கல்வி சார்ந்த திரந்த மூல திட்டம் கல்வி நிருவனங்களின் நிதி மேலன்மை, வழங்கப்படும் ஆய்வுகள்,
மனித்வள மேலான்மை, மாணவர் பதிவ, மற்றும் பல வேலைகளை செய்தாலும் அது தனிப்பட்ட ஒருவரின்
தேவையால் உருவானது அல்ல. அது ஒரு துரை சார்ந்த தேவையை அடிப்படையாக கோண்டது.
ஆனால் அது முற்றிலும் நேரடியாக அந்த துரையின் அனுபவம் மட்டும் சார்ந்த்தால் அதில் ஏர்படும் குரைகள்
அவர்களுக்கு நன்கு புலப்படும். இது சிறந்த மென்பொருள் உருவாக ஏதுவாக இருக்கும் ஏன் என்றால்
பயண்பாட்டு கருத்துகள் சரியான திசையில் அமைந்துவிடு கிண்றது. இது மற்றவர்களின்
தேவையை தீர்க எழுதப்பட்டு விற்பனை செய்ய பட்டது அல்ல. ஆனால்
தனிப்பட்ட தேவைக்கு உருவாக்க பட்டு அத்தகைய சேவை தேவை
பட்டவர்களுடன் பகிர்ந்து கொள்ள பட்டது. அது ஒரு நோய்க்கு மருந்து கண்டு பிடித்து அந்த நோயை
முற்றிலும் அழிக்கும் நோக்கில் அது உள்ள அனைவரிணடமும் பகிர்ந்து கொள்வது போன்றது.
இந்த அத்தியாயம் எவ்வாரு திரந்த மூல திட்டந்தினை அரிமுக படுத்துவது என்பதை பற்றியது,
ஆனால் இதன் கருத்துகள் பொரும்பாலும் மருந்து வினியோகம் செய்யும் நிவனத்தை சார்ந்திருப்பதை
போன்று இருக்கலாம். அடிப்படை ஒன்றுதான்: அதாவது ஒரு சிரந்த மருந்தை உற்ப்பத்தி செய்து
அதை சரியானவர்களை தேர்ந்தெடுத்து அவர்களுக்கு அதன் பயன்பாட்டை புரியும் படி சேய்வதாகும்.
ஆனால் மென்பொருள் உற்ப்பத்தியில் நீங்கள் அதன் பயன் பாட்டாலரையும் வருங்கால ஆய்வு
மற்றும் மேன்படுத்துதலில் ஈடுபடும் படி தூன்டுவது அவசியம் ஆகிரது.
இலவச மேன்பொருள் வினியோகம் இரட்டிப்பு பணியாகும். அந்த மென்பொருள் பயன்
பாட்டாளர்களை ஈர்ப்பது மற்றம் உருவாக்குபவர்களை ஈர்பதும் அவசியம் ஆகின்றது. இந்த தேவைகள்
ஒன்றுக்கு ஒன்று முரன் பட்டவை அல்ல, ஆயினும் அறிமுகம் செய்வதில் சில ஆரம்ப சிக்கல்கள்
ஏர்படுத்த கூடியவை. சில தகவல்கள் இரு சாராருக்கும் அவசிமாகவும் மற்ற சில ஒரு சாராருக்கு மட்டும்
பயனுள்ளதாய் அமைந்து விடும். இரண்டு வகையான தகவல்களும் ஓரு சிரந்த அரிமுத்திற்கு சரியான
அலவில் தேவை படுகின்றன; அதாவது, படிப்பவரின் அந்த கட்டதிற்று தேவையான நேரம் மற்றும்
அற்றல் அடிப்படையின் தகவல்கள் சேர்க்கபட வேண்டும். அதி ஆற்றல் அதி பயண் தரவல்லதாக இருக்க
வேண்டும். இவ்வாரு அவை இரண்டும் சரிசீராக அமையாவிட்டால் மக்கள் அதிலை ஆர்வம் மற்றும்
நம்பிக்கை இலக்க வாய்பு உள்ளது.
இவற்றான் தோன்றும் நியாயமான முடிவு என்ன வென்றால்வழங்கப்படும் தோற்றம்
அடிப்படை முக்கியத்துவம் வாய்ந்தது. உருவாக்குபவர்கள் பொதுவாக இதனை
ஏற்று கொள்வது இல்லை. தொழில் திரமையில் பெருமிதம் கொள்வது அவர்களின் அடிப்படை
ஆர்வம். இதனால் இயற்கையாகவே அவர்கள் சந்தை படுத்துதல் மற்றும் மக்கள் தொடர்பில்
மிகவும் வெருப்பு காட்டுவது, தொழில் முரை வலைதல வடுவமைப்பவர்கள் பலமுரை
உருவாக்குபவர்களின் கடும் தாக்கத்தினை சந்திக்க வேண்டியுள்ளதும் ஆச்சர்யமானது அல்ல.
இது அருவருக்க தக்கது, ஏன் என்றால் சில சமயங்களில் வடிவமைத்தல்
முக்கியகாறணி, அரிமுப்படுத்துதல் அத்தகைய வடிவமைக்கும் செயல்தான்.
உதாரனமாக, ஒரு வருகையாளர் ஒரு திட்டதை பற்றி தவணிக்கும் முதல் செயல் அதன்
வலைதலம் எவ்வாரு காட்சி அளிக்கின்றது என்பதுதான். அந்து மற்ற அவசியமான் தகவல்
புரிந்து கொள்வதர்க்கு முன்பே அதன் கவர்ந்துகொள்ள படுகின்றது—ஏதேனும் சுட்டியினை
இயக்கு முன் அல்லது எழுதியவற்றை படிக்கும் முன்பே. அது அநீதியாக இருக்கலாம், ஆயினும்
முதல் கருத்துப்பதிவு உருவாக்கும் தோற்றத்தை யாராலும் தடுக்க இயலாது. ஓரு தளத்தின்
தோற்றம் திட்டத்தின் அறிமுகம் செய்தல் எத்தகைய அக்கறையுதடன் செய்யப்பட்டது என
காட்டுகின்றது. அக்கறையை மதிப்பிட மிக சிரந்த தனிக்கை கருவியை மனிதர்களிடம் இயல்பாக
உள்ளது. நம்மில் பெரும்பாலானவர்கள் முதல் பார்வையிலேயெ ஒரு தளம் சிரந்த அக்கறையுடன்
உருவாக்க பட்டதா அல்லது மிகவும் அவசரமாக செய்து முடிக்க பட்டதா என்பதை கூரவிடுவர்.
இதுவே ஒரு திட்டத்தின் முதல் தகவல் மேலும் இது மீதமுள்ள அனைது பகுதிகளுக்கும்
ஒரு தொடர்ந்த தாக்கத்தை ஏர்ப்படுத்தும்.
எனவே இந்த அத்தியாயத்தின் பெரும்பான்மையான பகுதி எத்தகைய தகவல்கள் கொன்டதாக
உங்கள் தளம் அமைய வேண்டும் என்பதை விவாதிக்கிரது, தோற்றம் மற்றும் பருப்பொருள் அமைப்பின்
முக்கியத்துவத்தையும் மறக்க வேண்டாம். இந்த தளம் இரண்டுவிதமான விருந்தினர்களுக்கும்
பொதுவானதாக உள்ளதால்—பயனர்கள் மற்றும் உருவாக்குபவர்கள்—மிகவும்
கவனத்துடன் தெளிவு மற்றும் வழிகாட்டுதல் தகவல்களை கொடுக்க வேண்டும். இது வலை
வடிவமைப்பு பற்றிய ஒரு ஆய்வுக்கட்டுரை இல்லை என்றாலும், ஒரு கொள்கை பற்றி
குறிப்பிட வேண்டியுள்ளது, முக்கியமாக ஒரு தலம் பலதரப்பட்ட பார்வையாளர்களை பொற்றுள்ள
போது: அவர்கள் ஒரு எந்த சுட்டியை பயன்படுத்தினால் எங்கு இட்டு செல்லும் என்ற
தோராயமான தோற்றம் அதனை இயக்காமலே பெர வேண்டும். உதாரணமாக, ஒரு
இனைப்பை பார்பதில் இருந்தே அது பயனர் ஆவணத்தின் இணைப்பு
என்றும் நிச்சமாக உருவாக்குபவர்களுக்கு கொடுக்கப்பட்டது இல்லை என்றும் வெளிப்படையாக தொரிய
வெண்டும். தலந்தை இயக்குவது தகவல் வழங்க என்றாலும் அது வசதி அளிப்பதாகவும் இருக்க
வேண்டும். ஒருசில இணக்கமான காரணிகள், எதிர்பார்க்கப்படும் இடங்களில், வழங்கப்படுவது
பயனர் மற்றும் உருவாக்குபவர்கள் ஈடுபட வேண்டும் என்பதை தீர்மானிக்கும். இது அந்த திட்டம்
அதன் அனைத்து கூருகளையும் ஒருங்கினைத்து கொடுத்துள்ளதா, அனைவரும் கேட்க்க விழையும்
கேள்விகள் மற்றும் அவற்றிக்கு மிக எளிதில் புரிந்து கொள்ளும்படி முயற்சி எடுத்து பதில்கள்
கூரப்பட்டுள்ளதா என்பதை எல்லாம் குறிக்கிரது. அப்படு கொடுக்கபட்ட சிரந்த தோற்றத்தால்
அந்த திட்டம் வழங்கும் செய்தி: “நீங்கள் பங்கு இதில் பெருவதால் உங்கள் நேரம் விரயம் ஆகது”
அதைத்தான் அனைவரும் கேட்க விரும்புவர்.
நீங்கள் “தொகுக்கபட்ட வழங்கு தலங்களை”(canned hosting) பயன் படுத்தினால்
(see ), ஒரு சிரந்த பயன்
அது ஒரேமாதிரியான திட்டங்களுகு பொதுவான அடிப்படை பரவமைப்புகள் வழங்குகின்றது, மேலும்
அது அறிமுகம் செய்ய எளிதானது. அந்த பரவமைப்புகளை சிரப்பு மாற்றங்கள் செய்ய இயலும், சில
அடிப்படை கட்டுப்பாடுகளுடன் இருந்தாலும் அதன் அடிப்படை பரவமைப்பு பயனர்களுக்கு தேவைபடும்
முக்கிய தகவல்களை வழங்க தூன்டுதலாக உள்ளது.
ஆனால் முதல், சுற்றி தேடி பாருங்கள்
ஒரு திறந்த மூல திட்டம் துவங்குவதற்கு முன், முக்கியமான எச்சரிக்கை ஒன்று உள்ளது:
எப்போதும் முதலில் நீங்கள் வேண்டும் சேயல்கள் செய்யும் திட்டம் ஏற்கனவே உள்ளதா
என்று சுற்றி தேடி பாருங்கள். நீங்கள் தீர்க்க உள்ள பிரச்சனைகளை வேறு யாராவது உங்களுக்கு முன்
தீர்த்து இருக்க வாய்ப்புகள் அதிகம் உள்ளது. அவ்வாரு தீர்க்கப்பட்டு அவர்கள் அதை
கட்டற்ற மென்பொருளாக வழங்கி இருந்தால் அதை நீங்கள் மீன்டும் சேய்வது அவசியம் அற்றது.
இறுப்பினும் அவ்வாரு தேடுவதற்கும் விதிவிலக்கு உள்ளது: உங்கள் ஆய்விர்க்காக நீங்கள் உருவாக்க
நினைத்தால் ஏற்கனவே குறியீடுகள் இருந்தாலும் பயன் அற்றது; அதேபோல் நீங்கள் உருவாக்குவது
முற்றிலும் தனித்துவம் பெற்றது என்றாலும் மற்றவர் உருவாக்கி இருக்க முற்றிலும் வாய்ப்பு இல்லை.
பொதுவாக தேடி பார்ப்பது ஒன்றும் தேவையற்ற செயல் அல்ல அதன் பயன் மிக அதிகமாக இருக்கும்.
உங்களில் தேடு பொறி எந்த திட்டங்களையும் காட்ட வில்லை எனில், நேரடியாக
github.com, on ohloh.net, freecode.com, on sourceforge.net, மற்றும்
கட்டற்ற மென்பொருள் அறக்கட்டளையின் அகராதியில்
directory.fsf.org தேடி பேருங்கள்.
நீங்கள் தேடுவது சரியாக கிடைக்கா விட்டாலும், அதற்கு மிகவும் இனையானது
உங்களுக்கு கிடைக்கலாம் மேலும் ஆரம்பத்தில் இருந்து உருவாக்காமல் சில செயல்பாடுகளை
மட்டும் அதில் இனைந்து நீங்கள் உருவாக்கலாம்.
உங்களிடம் இருப்பதில் இருந்து துவங்குதல்
நீங்கள் தேடி பார்த்து, நீங்கள் விரும்பியது போல் உங்கள் தேவையை எதுவும்
சரியாக செய்வது போல் தோன்றவில்லை என்ற உடன், நீங்கள் புதிதாக ஒரு திட்டத்தை
நீங்களாகவே உருவாக்க நினைக்கிறீர்கள்.
இப்பொழுது என்ன?
கட்டற்ற மென்பொருள் திட்டம் நிருவ உள்ள கடுமையான பிரச்சனை தனிப்பட்ட
நோக்கத்தை பொதுவான ஒன்றாக மாற்றுவதை. உங்களுக்கு அல்லது உங்கள் நிறுவனத்திர்க்கு
அதன் தேவை பற்றி உள்ள தெளிவான எண்ணம் உலகிற்கு புரியும்படி எடு கூருவது மிகவும் சிரம்மான
ஒன்று. நீங்கள் மற்ற நிறுவுனர்களுடன் இனைந்து சில முடிவுகள் எடுக்க வேண்டும் அதில்
உங்கள் திட்டம் உண்மையில் என்ன—அதாவது அதன் வரம்புகள், அது எதை
செய்யாதுமற்றும் அது எதை செய்யும்— என்பது மற்றும் அதை பற்றிய ஒரு
பணி அறிக்கை எழுதுவது பற்றி. இது பொதுவாக மிக கடினமானது அல்ல, ஆனால் இது சில
சமயன் சொல்லப்படாத ஊகங்கள் மற்றும் அந்த திட்டத்தின் மீது உள்ள கருத்து வேறுபாடுகளை
வெளிப்படுத்தும், காலதாமதமாக இல்லாமல் இப்போது அவை தோன்றுவது நல்லது இப்போதுதான்
அவற்றை எளிதில் தீர்க்கவும் இயலும். அடுத்த படி, திட்டத்தை பொது நுகர்வுக்காக தொகுப்பது,
மேலும் உண்மையில் அது வேலைபளு உள்ள செயல்.
அது மிகவும் கடினமாக இருப்பதற்கு காரணம் அதில் அனைவரும் ஏற்கனவே அறிந்தவற்றை
தொகுத்து ஆவணப்படுத்துதல்—”அனைவரும்”, அதாவது அதில் இப்போதுவரை ஈடுபட்டவர்கள்
அனைவரும். அதனால் அவர்களுக்கு எந்த உடனடி பயனும் இல்லை. அவர்கள்
திட்டத்தின் கண்ணோட்டம் பெற README கோப்பினை படிக்க
அவசியம் இல்லை. அவர்களுக்கு ஏற்று கொள்ள பட்ட நியமங்களை பின்பற்றி நன்கு கவணத்துடன
குறியீடுகளை ஏற்பாடு செய்ய வேண்டியது இல்லை. குறியீடுகள் எப்படி அமைக்க பட்டு இந்தாலும்
அது அவர்களுக்கு கவலை இல்லை, அது இயங்கும் எனில் அவர்களுக்கு எப்படி பயன்படுத்த
வேண்டும் என்பது தேறியும். அதன் அடிப்படை கட்டமைப்பு நன்கு ஆவணப்படுத்த படாமல்
இருந்தாலும் அவர்களுக்கு கவலை இல்லை; அதை அவர்கள் நன்கு அறிந்திருப்பார்கள்.
அதே சமையம் புதியவர்களுக்கு அது முற்றிலும் அவசியம் தேவை. நல்ல வேலையாக
அவர்களுக்கு அது உடனடி தேவையாக இருக்காது. பொது நுகர்வுக்கு கொடுக்கும் முன
அனைத்து விதமான சாதனங்களையும் கொடுக்க வேண்டிய அவசியம் கிடையாது. ஒரு பரிபூரண
உலகில், அனைத்து புதிய கட்டற்ற மென்பொருள் திட்டங்களும் முழுமையான திட்ட வடிவம், பயனர்
கையேடு(எவை செயல்பாட்டிலும் எவை வருங்கால திட்டத்திலும் உள்ளன என்ற தெளிவான குறிப்புடன்),
அழகாக தொகுக்க பட்ட குறியீடு, அனைத்து தலங்களிலும் இயங்க கூடிய தன்மை, மற்றும் பல பண்புகளுடன்
தோன்றுகிறது. நடைமுரையில் இத்தகைய சாதனங்கள் அனைத்தும் காலம் தால்துபவை மற்றும்
இதில் திட்டம் துவங்கியபில் மற்றவர்கள் உதவ வாய்ப்புகள் அதிகம்.
எது அவசியம் என்றால், புதியவர்கள் எந்த தங்கு தடையும் இன்றி
புரிந்து கொள்ள எளிமையான ஆரம்ப தடைகளை கடக்க அக்கரையுடன் நேரம் செலவிட்டு அரிமுக
ஆவணம் தரிப்பது தான். இதை தொடக்க ஏற்றிக்கு ஒரு முதல் படி என நினைக்க வேண்டும்,
இது திட்டத்தின் ஆரம்ப நிலைக்கு குறைந்தபட்சம் ஊக்கம் வர உதவும். நான் இந்த வாசற்படியை
ஹாக்டிவேஸன் ஆற்றல் என கேட்டிருக்கிறேன்: புதுமுகம் ஒருவர்
அழிக்கும் ஆற்றலில் ஒரு அளவு திரும்பி பெரமுடியும் என்ற என்ம் அவருக்கு தோன்ற வேண்டும்.
உங்களு முதல் குறிக்கோள் அந்த ஹாக்டிவேஸன் ஆற்றல் அளவு குறைத்து மற்றவர்களுக்கு ஊக்கம்
தர வேண்டியதுதான்.
கீழ் உள்ள ஒவ்வொரு துனை பகுதிகளும் புதிய திட்டத்தை உருவாக் வேண்டிய ஒரு குறிப்பிட்ட
காரணியை விளக்கு கின்றன. அவை பொதுவாக பயனர் எப்படி எதிர் பார்ப்பார் என்ற அடிப்படையில்
தொகுக்க பட்டுள்ளன, ஆயினு உங்கள் தயாரிப்பு முற்றிலும் மாருபட்டு இருக்கலாம். இவற்றை
நீங்கள் ஒரு ஒப்பீட்டு மாதிரி போன்று பயன் படுத்தலாம். ஒரு திட்டத்தை துவங்கும் முன்னர் அவை
அனைத்தும் உள்ளனவா இல்லை என்றால் அதன் விலைவுகள் என் என்பதையும் தெரிந்து கொள்ளுங்கள்.
ஒரு நல்ல பெயர் தேர்வு செய்யுங்கள்
நீங்கள் உங்களை உங்கள் திட்டத்தை பற்றி தொரிந்து கொண்ட ஒரு புதியவராக நினைத்து பாருங்கள்,
அவர் பொதுவாக சில கடினமான செயல்களுக்கு மென்பொருள் தீர்வு காண தெடதல் நடத்துபவராக இருந்திருப்பார்.
அவர் முதலில் பார்ப்பது உங்கள் திட்டத்தின் பெயராக இருக்கு.
ஒரு நல்ல பெயர் உங்கள் திட்டத்தை கண்டிப்பாக வெற்றி பெற்றதாகவோ அல்லது கெட்ட பெயர்
கண்டிப்பாக தோல்வியை தேடித்தரும் என்றோ செல்ல இயலாது\—உண்மையில்,
மிக மோசமான பெயர் அப்படி செய்யலாம், நமது அனுமானம் அப்படி
தோழ்வியை எதிர் பார்த்து எவரும் திட்டத்தை உருவாக்குவது இல்லை. ஆனால் தவரான பெயர் அதை
நினைவுகூர கடினமாகவும் அல்லது எவரு அதர்க்கு முக்கியதுவம் தராமலும் போக செய்யலாம்.
ஒரு நல்ல பெயர்:
அதன் அடிப்படை செயல் பாட்டை அல்லது அதன் செல் எதை சார்ந்துள்ளது
என்பதை குறிக்கும், அதனால் அந்த பெயரை நினைக்கும் போது அதன் செயல்பாடு
நினைவு கூருவதும் எளிதாக அமைந்துவிடும்.
நினைவில் கொள்ள எளிதானது. ஆங்கிலம் இனையத்தின் பொது மொழியாக
இருப்பல்: “நினைவு கூர எளியது” என்றால் அது “ஆங்கிலம் பேசுபவர்க்கு நினைவு
கூர எளியது” என கூருவதில் எந்த சுற்றி வலைப்பதும் இல்லை; அதனால் தாய்மொழி
உச்சரிப்புக்கு முக்கியத்துவம் உள்ள பெயர் என்றால் மற்ற மொழி பேசுபவர்க்கு அது மிக
கடினமாக இருக்கும். அது அவ்வாரு பெயரிட அவசியம் இருந்து அது நினைவு கூர கடினமாக
இல்லை எனில் முயற்ச்சிப்பது தவறில்லை; ஆயினும் மற்றவர்கள் அதனை சரியாக
உச்சரிப்பார்கள் என கருத இயலாது.
அது வேரு ஒரு திட்டத்தின் பெயராகவோ அல்லது பதிப்பு முத்திரை பெயர் மீரலாகவோ
இருக்காது. இது ஒரு சிரந்த பண்பு மட்டும் இன்றி சட்ட சிந்தனையுடன் செய்யப்பட்டது. நீங்கள்
அடையாள குழப்பம் உருவாக்க விரும்ப மாட்டீர்கள். அது இணையத்தில் ஏற்கனவே உள்ளதா
என்று கண்காணிக்க கடுமையாக இருக்கும்.
முந்தைய பகுதியில் குறிப்பிடப்பட்டுள்ள வளங்கள்
அதர்க்கு பயன் உள்ளதாக இருக்கும்.
அமேரிக்க காப்புரிமை பெற்ற முத்திரை பெயர்களை இதில் தேடலாம்
uspto.gov.
சாத்தியம் இருப்பின் பின் வரும் மேல் தள இனையத்தில் இருக்கும்
.com,
.net, மற்றும்
.org. நீங்கள் ஏதேனும் ஒன்றை,
உதாரனமாக .org, உங்கள் திட்டத்தின்
அதிகார பூர்வமான தளமாக தேர்வு செய்ய வேண்டும்; மற்ற இரன்டையும்
அதர்க்கு முன் அனுப்புமாரு வழி செலுத்த வேண்டும் அது மற்றவர் அந்த
தளப்பெயரை பதிவு செய்து குலப்பம் ஏற்ப்படுத்தாமல் இருக்க உதவும்.
ஒருவேலை நீங்கள் உங்கள் திட்டத்தை தொகுக்க பட்ட வேரு தளம் வழியாக
அரிமுகம் சேய்ய நினைத்தாலும் (see
), அதை
உங்கள் தனித்துவமான தளத்தின மூலம் முன் அனுப்புமாரு செய்யலாம்
இது பயனாலர்களுக்கு எளிதில் நினைவு கூரும்மாரு அமையும்.
சாத்தியம் இருப்பின் பின், அது Twitter மற்றும் ஏனய
பலுக்கல் தளங்களில் பயனர் பெயராக இருக்கும். இதை பற்றிய மேலும் விவரங்களுக்கு
-ஐ காண்க.
முக்கியமான பெயர்வெளிகளில் பெயரை பெற்றிருங்கள்
பெரிய திட்டங்களுக்கு, அதன் தொடர்புடைய பல தரப்பட்ட பெயர்வெள்களில்
பெயர் பதிவு பெற்றிருப்பது சிரந்ததாக இருக்கும். பெயர்வெளி என்று நான் குறிப்பிடுவது
தளப்பெயர்களை மட்டும் அல்லாமல் பொதுவெளியில் உள்ள சேவைகளில் கணக்கு பெயராக
(பயனர் பெயர்) பெற்றிருக்க வேண்டும், அது பொதுவாக அந்த திட்டத்தை பரிந்துரைக்க
உடவியாக இருக்கும். அனைத்து பொது வெளிகளிலும் ஒரே மாதிரியான பெயர்களை பதிவு
செய்திருந்தால் அது மற்றவர்களை உங்கள் திட்டத்தில் ஈடுபட தூன்டும் வகையில் இருக்கும்.
உதாரனமாக, ஜினோம் கட்டற்ற மேசைத்தள திட்டத்திர்க்கு gnome.org என்ற தள்ப்பெயர்
அவர்கள் gnome.com அல்லது gnome.net என்ற பெயர்களை
பதிவு செய்ய பெறவில்லை, இருப்பினும் அது போதுமானது —
நீங்கள் பதிவு பெற்றிருப்பது .org மட்டும் இருந்தாலே போதுமானது. அதுதான் பொதுவாக கட்டற்ற
மென்பொருள் திட்ட தளங்களின் முதலில் தேடப்படும் தளமாக இருக்கிரது. அப்படி அவர்கள்
"gnome.org" பெர இயலாமல் போனால் அதர்க்கு மாற்று வழி
"gnomeproject.org" என்ற தளத்தை பதிவு செய்யலாம் அவ்வாரு இத்தகைய குலப்பங்களை
தீத்து கொண்ட திட்டங்கள் நிரைய உள்ளன.,
@gnome ட்விட்டர் கைப்பிடி, gnome
Identi.ca பயனர்பெயர் Identi.ca கட்டற்ற மென்பொருள் உருவாக்குபவர்கள் பயன்படுத்தும்
ஒரு பலுக்கல் / சமூக வலைப்பின்னல்; அதன் குறியீடு
pump.io என்ற தளத்தில் கட்டற்ற மென்பொருளாக தரப்பட்டுள்ளது. உருவாக்குபவர்கள்
சார்ந்த திட்டங்களுக்கு, அனைத்து திட்ட நிலைகளையும் குறுச்செய்திகளாக
— பேச்சுவழக்கில் "tweets" எனப்படும் —
Identi.ca மற்றும் Twitter இல் பதிவிட நான் பரிந்துரைக்கிறேன். Identi.ca பயனர்கள்
ட்விட்டர் பயனர்களை விட எண்ணிக்கையில் மிகக் குரைவு என்ற போதும் அவர்களி கட்டற்ற
திட்டங்களில் ஆர்வம் கொண்டவர்கள் மிக அதிக விழுக்காட்டில் உள்ளனர், நான் இதை
எழதகையில் 2013-ல் இத்தகைய நிலமை இருந்தது குரைந்து மற்றும் சில வருடம் அது
தொடரும்.,
gnomeஎன்ற GitHub.com பயனர்பெயர்அதன் அடிப்படை குறியீடு
git.gnome.org-ல் இருப்பினும்,
பெரும்பாலான உருவாக்குபவர்களுக்கு ஏற்கனவே கிட்ஹப் தெரிந்திருந்ததால் அவர்கள் கிட்ஹப்பில்
ஒரு பிரதியையும் பராமரித்து வருகின்றனர், மற்றும் அவர்களுக்கான
தனித்துவமான ஐஆர்சி தள வழங்கி இருப்பினும்(நிலய பெயர்வெளிகளை கட்டுப்படுத்தவே),
freenode IRC இனைப்பில்(see ) #gnome
என்ற நிலையம் அமைத்துள்ளனர்.
இவை அனைத்தும் ஜினோம் திட்டத்தை தேடுவதை மிக எளிதாக்கி உள்ளன: அதிப்படியான
பங்களிப்பாளர்கள் விரும்பும் வகையில் இது சிர்ந்த வழியாகும். ஜினோம் ஆயிரக்கணக்கான
பங்களிப்பாளர்கள் மற்றும் கிளைகள் கொன்ட ஒரு மிகப்பெரிய மற்றும் கடினமான திட்டம்;
எனவே ஜினோம் புதிய திட்டங்களைவிட எளிதில் தேடிகண்டுபிடிக்கும் படி அமைவது அவசியம்,
அதன் காரணமாக அதில் இனைந்து பங்களிக்க எளிதாக இருக்கும். அதே சமையம் உங்கள்
திட்டம் பலதரப்பட்ட தளங்களில் பெயர்வெளிகளை கொண்டிருப்பது கண்டிப்பாக
தவறானது அல்ல, மேலும் அது சில சமையம் உதவும். எனவே
நீங்கள் திட்டங்களை உருவாக்கும் பொழுது அதன் வலைதள கைபிடி எவ்வாரு இருக்க வேண்டும்
என்பதை அறிந்து அதன் பெயர்களை நீங்கள் அதிகம் எதிர் நோக்கும் வலைதள சேவைகளில்
பதிவு செய்து விடுங்கள். மேலே குறிப்பிட்ட அனைத்தும் சரியான துவக்கத்தை தரலாம் எனினும்
உங்களுக்கி மற்ற எவை தொடர்புடையதாக உள்ளதோ அவை அனைத்திலும் பதிவது அவசியம்.
ஒரு தெளிவான குறிக்கோள் அறிக்கை வேண்டும்
திட்ட தளத்தை கண்டுபிடித்த பின்னர் அவர்கள் பார்க்க விரும்புவது திட்டத்தின்
சிரு குறிப்பு அல்லது குறிக்கோள் அறிக்கை, எனவே அவர்கள் மேலும் அரிந்து கொள்ள வேண்டுமா இல்லயா
என ஒரு முடிவிர்க்கு (30 நிமிடங்களுக்குல்) வர இயலும். அது முதல் பக்கத்தில் நிரந்தரமாக இடம்
பெர வேண்டும்.
அந்த விழக்கம் மிகவும் உருதியானதாகவும், எல்லையுடனும், மற்றும் அவற்றிக்கு எல்லாம்
மேலாக, சுருக்கமானதாகவும் இருக்க வேண்டும். அதர்க்கு உதாரனமாக
hadoop.apache.org
இல் இருந்து:
Apache™ Hadoop® என்பது நம்பகமான, வழப்படுத்த கூடிய,
ஒரு விரவல் கணினி திட்டம்.
அப்பாச்சி ஹடூப் மென்பொருள் நூலகம் ஒரு கட்டமைப்பு அது
விநியோகம் செயிது பெரிய தரவுகளை ஆய்வு செய்ய ஒரு நிரலாக்க மாதிரியை அமைக்கிறது.
இது ஒன்று முதல் ஆயிரக்கணக்கான தனி கணித ஆற்றல் மற்றும் சேமிப்பு கலன்கள் கொன்ட
வழங்கிகள் வரை எளிமையாக மேன்மை படுத்த தக்க வகையில் வடிவமைக்கப்பட்டுள்ளது. நம்பகத்தன்மைக்கு
வன்பொருளை சார்ந்து இல்லாமல், அந்தன் மென்பொருள் நூலகமே பழுதுகளை கண்டுனர்ந்து
கையாலும், எனவே நம்பகத்தன்மையை பழுது பட கூடிய கணினி கொத்துகளுக்கே நேரடியாக
வழங்கு கின்றது.
நான்கே வரிகளில், படிப்பவர்களில் முன் அரிவை முற்றிலும் சார்ந்து, அனைத்து முக்கிய
அம்சங்கள் அனைத்தையும் கூரி விட்டனர். அது ஓரு முக்கிய அம்சம்: அதாவது ஒரு குறைந்த
பட்ச தகவல் பெற படிப்பவர் தயார்நிலை நிலை உள்ளதாக கருதிக் கொள்வது பரவாயில்லை.
படிப்பவர் “கொத்துகள்” மற்றும் “அதிக நிலைப்புதன்மை” பற்றிய பொதுமான அரிவை பொற்றிருக்கவில்லை
என்றால் அவர்கள் ஹடூபால் எந்த பயனும் அடைய இயலாது, எனவே அப்படி பட்ட அடுப்படை பெராத
வர்களுக்காக எழுதுவது அவசியம் அற்றதாகிரது. அந்த "பழுதுகளை செயலி மட்டத்திலேயே
கண்டுனர்ந்து கையாலும் வடிவமைப்பு" பெரிய அளவிலான கணின் கொத்துகள் பராமரித்து அனுபவம் மிக்க
பொறியாலர்களும்கு மட்டும் விழங்கும்—இத்தகைய வார்தைகளை அவர்கள் பாத்த மட்டிலேயே
ஹடூப் உருவாக்கியவர்கள் அதன் உலகத்தை புரிந்து கொண்டுள்ளதை அரிவர் மேலும் அதில் பங்களிக்க
விருப்புவர்.
குறிக்கோள் அறிக்கை படித்த பின்னர் ஆர்வமாக இருப்பின் மேலும் அரிந்து கொள்ள விரும்புபவர்கள்,
பொதுவாக உருவாக்குபவர் அல்லது பயனர் கட்டூரைகள், மேலும் சில வற்றை பதிவிரக்க விரும்புவார்கள்.
அப்படி செய்யும் முன்னர் அவர்கள் அது கட்டற்ற மென்பொருளா என தெரிந்து கொள்வர்.
இது கட்டற்ற திட்டம் என்று அறிவித்து விடுங்கள்
முதல் பக்கம் மிகவும் தெளிவாக இது ஒரு கட்டற்ற திட்டம் என்று எந்தவித குழப்பங்களும்
இன்றி அறிவிக்கும் படி இருக்க வேண்டும். இது அவசியமானதாக தோன்றினாலும் அதை
எப்படி பல திட்டங்கள் தவரி விட்டன என்பது வியப்பாக இருக்கும். நான் பல கட்டற்ற திட்ட தளங்களில் அவை
கட்டற்ற திட்டங்கள் என்ற அரிவிப்பை முதல் பக்கத்தில் காணவில்லை அது மட்டும் இன்றி, இது கட்டற்ற திட்டம்
என்று அப்பட்டமாக தெளிபடுத்தும் அறிவிப்பு கூட இல்லாமல் இருந்திருக்கின்றன. சில சமையம் இத்தகைய
அதி முக்கிய குறிப்புகள் பதிவிரக்க பக்கம், அல்லது உருவாக்குபவர்கள் பக்கம், அல்லது ஒரு சில சுட்டி இயக்கங்கள்
தேவைபடும் வேரு ஏதேனும் பக்கங்களில் பயன் படுத்தி இருக்கலாம். இன்னும் அதீதமான திட்டங்களில் அதன்
உரிமம் பற்றி வலை தளத்தில் எங்கும் வழங்கப்படவில்லை—அதை கண்டுனர ஒரே வழி அதனை பதிவிரக்கி
அதன் உரிமம் பற்றிய கோப்பினை சரிபார்த்தல் மட்டுமே.
தயவு கூர்ந்து அத்தகைய தவறை செய்ய வேண்டாம். அத்தகைய அலட்சியப்படுத்துவதனால் பல பயனர்கள்
மற்றும் உருவாக்குபவர்களை இலக்க நேரிடலாம். ஆரம்பத்திலேயே, குறிக்கோள் அறிக்கைக்கு கீழாகவே,
மிகத்தெளிவாக இது “கட்டற்ற மென்பொருள்” அல்லது “திரந்த மூல திட்டம்” என்பதை குறிப்பிடுக மேலும் அதன்
மிகச்சரியான உரிமம் பற்றியும் குறிப்பிடுக. உரிமங்களை தேர்வு செய்ய ஒரு சிரந்த வழிகாட்டுதல்
என்ற பின்வரும் பகுதியில்
தரப்பட்டுள்ளது, மற்றும் உரிமம் சார்ந்த சிக்கல்கள் பற்றி விரிவாக
விவாத்க்க பட்டுள்ளது.
இந்த நிலையில், நமது அனுமான பார்வையாளர் —ஒன்று அல்லது குறைவான
நிமிடத்திலேயே— பங்களிக்க விரும்புவதாக தீர்மானித்து இருப்பார், பின், இன்னும் ஐந்து நிமிடம்
அதிகப்படியான ஆய்வு நேரம் செலவிடுவதாக கருதிலான். பின்வரும் பகுதி அந்த ஐந்து நிமிடந்தில்
பார்க்க வேண்டியது என்ன என்பதை விளக்குகிறது.
அம்சங்கள் மற்றும் தேவைகளின் பட்டியல்
அந்த திட்டதின் அம்சங்கள் என்ன எனபதை பற்றிய ஒரு சிறிய பட்டியல்
(ஏதேனும் நிறைவு பெறாமல் இருப்பினும் நீங்கள் "திட்டமிடப்பட்டுள்ளது"
அல்லது "செயல்நிலையில் உள்ளது" என்ற குறிப்புடன் இங்கு பட்டியல்
இடலாம்), மற்றும் எந்தவிதமான கணினி சூழல் இயக்க தேவைப்படும் என்றும் குறிப்பிட வேண்டும்.
உங்கள் திட்டம் பற்றி விவரம் கேட்பவருக்கு எதை சொல்ல விரும்புவீர்கள் எனபதை நினைத்து
அம்சங்கள்/தேவைகளின் பட்டியலை உருவாக்குங்கள். இதை நியாயப்படி குறிக்கோள் அறிக்கையின்
பொருத்தமான விரிவாக்கமாக என்னலாம். உதாரனமாக, குறிக்கோள் அறிக்கை பின்வருமாரு கூரலாம்:
அதிக என்னிக்கையில் ஆன கோப்புகளில் தேடல் மற்றும் சுட்டுவரிசையாக்கம்
செய்ய கூடிய தேடல் இயந்திரம் ஒன்றை உருவாக்குபவர்கள் பயன் படுத்தும் வகையில் சிரப்பான API
தொகுப்புகளுடன் உருவாக்குவது.
அம்சங்களை மற்றும் தேவைகள் பட்டியல் குறிக்கோள் அறிக்கை பற்றிய விளக்கங்கள் இவ்வாரு
தரலாம்:
அம்சங்கள்:
சாதாரன உரை, HTML மற்றும்
XML வடிவங்களை தேடவல்லது
சொல் அல்லது வாக்கிய தேடல்
(திட்டமிடப்பட்டுள்ளது) தெளிவற்ற பொருத்தம்(Fuzzy matching)
(திட்டமிடப்பட்டுள்ளதுs) சுட்டு வரிசைகளை வளர்ச்சிக்கு
தக்கவாரு புதுப்பித்த்
(திட்டமிடப்பட்டுள்ளது) தொலை வலை தள அட்டவனை படுத்துதல்
தேவைகள்:
Python 2.2 அல்லது அதனினும் புதியது
சுட்டு வரிசைகளை சேமிக்க தேவையான இடம்
(தரவுகளை விட சுமார் இரண்டுமடங்கு)
இந்த தகவலுடன், வாசகர்கள் அதில் வேலை செய்ய ஏதேனும் நம்பிகை உணர்வை பெற முடியும்,
மேலும் அவர்கள் அதில் உருவாக்குபவராக இனையவும் கூடும்.
வளர்ச்சி நிலை
பார்வையாளர்கள் வழக்கமாக ஒரு திட்டம் எத்தகைய நிலையில் உள்ளது என்பதை அறிந்து கொள்ள
வேண்டும். புதிய திட்டங்களுக்கு, அவர்கள் திட்ட வாக்குறுதி மற்றும் அதன் தற்ப்போதைய நிலை பற்றி
தெறிந்து கொள்ள விரும்புவர். முதிர்ந்த திட்டங்களுக்கு, அது எவ்வாரு தொடர்ந்து பராமரிக்கப்படுகிறது,
அதன் புதிய வெளியீடுகள் சீரான இடைவெளியில் வழிங்கப்படுகிறதா, பிழை அறிக்கைகளுக்கு எப்படி
பதிலளிக்க படுகிறது, மற்றும் பல தகவள்களை அவர்கள் தெறிந்து கொள்ள விரும்புவர்.
இந்த கேள்விகளுக்கு பதில் கூர வெவ்வேறு வழிகள் உள்ளன. அதில் திட்டத்தின் குருகிய
கால நோக்கங்கள் மற்றும் தேவைகள் பற்றி பட்டியல் கொன்ட திட்ட நிலை பக்கம் இருப்பதும் ஒன்று
(உதாரணமாக, அதில் ஒரு குறிப்பிட்ட வகையான நிபுணத்துவம் உள்ள உருவாக்குபவர்களில் தேவை
பற்றி குறிப்பிடுவது). அதில் கடந்த வெளியீடுகளின் வரலாறு, அதன் அம்சங்கள் பட்டியல் கொடுக்க
முடியும், அது பற்வையாளர்களுக்கு திட்டத்தின் "முன்னேற்றம்" எவ்வாரு வரையறை செய்யபட்டு,
அதன் படி எவ்வளவு விரைவாக முன்னேற்றம் பெறுகிரது என அறிய உதவும். சில திட்டங்கள் தங்கள்
வளர்ச்சி நிலை பக்கம் ஒரு திட்ட அறிக்கை போன்று அதன் வருங்கால அம்சங்களுடன் கொடுத்துள்ளனர்:
கடந்த கால நிகழ்வுகள் அவை நிகல்ந்த சரியான தேதியுடனும், வருங்கால திட்டங்களை அவை நடங்க
எதிர்பார்க்க படும் தேதியுடனும் குறிப்பிட பட்டு இருக்கும்.
மற்றொரு முறை — முதலில் கூரியதில் இருந்து முற்றிலும் வேறுபட்டது
அல்லாமல், மேலும் அதனுடன் இனைத்து செயவதால் சிறந்ததாகவும் இருக்கும் —
பல்வேரு பட்ட தானியங்க கூடிய குறியீடுகள் மற்றும் காரணிகளை அந்த திட்ட முதல் பக்கத்தில் அல்லது/மேலும்
உருவாக்குபவர்களில் பக்கத்தில், சேகரிக்கபட்ட பல முக்கிய தகவளுடன் தருவது திட்டத்தின் வளர்ச்சி பற்றிய
தேற்றத்தை உருவாக்கும். உதாரணமாக, புதிய செய்திகளை அல்லது அறிவிப்பை பற்றிய டிவிட்டர் அல்லது
குறு செய்தி தளங்களில் காட்டுவது, திட்டத்தின் வளர்ச்சியுடன் தொடர்புடைய புதிய வெளியீட்டின் கால
அளவை குறிப்பது, பிழை நிகழ்வுகளை காட்டுவது(பிழை பதிவுகள், பதில் கூரப்பட்ட பிழைகள் அனைத்தும்),
அஞ்சல் பட்டியல் மற்றும் கருத்துகளை விவாதிக்கும் மன்ற நிகள்வுகளை இனைப்பது போன்ற பலவற்றை கூரலாம்.
அப்படி பட்ட அனைத்து காரணிகளும் அதன் தொடர்பான மற்ற விவரங்களை கோடுக்க வேண்டும்: உதாரணமாக,
"புதிய பிழைகள்" என்ற இனைப்பு பிழை தொகுக்கும் பக்கதிர்க்கு இட்டு செல்ல வேண்டும் அல்லது குறைந்தது
விரிவாகி மேலும் தகவள் தர வேண்டும்.
உண்மையில், சிரிய வேருபாட்டுடன் கூடிய இரண்டு விதமான "வளர்ச்சி நிலைகள்" இங்கு விழக்க பட்டுள்ளன.
ஒன்று முறைப்படி கூரப்பட்டது: அதில் திட்ட நிலைபாடு குறிப்பிட்ட இலக்குகளுடன் எத்தகைய நிலையில் உள்ளது,
மற்றும் எவ்வளவு விரைவாக முன்னேறி செல்கிரது எனபது விழக்க பட்டிருக்கும். மற்றது சற்று முறை சார்ந்தது இல்லை
அனால் பயனுள்ளது: திட்டம் எவ்வாரு துரிதமாக நடைபெருகிறது? ஏதேனும் நிகழ்ந்து கொண்டு உள்ளதா?
எவரேனும் இப்போது செயல்களை செய்து முடிக்க உள்ளனரா? போதுவாக அந்த கடைசி கேள்விக்கு இல்லை என்ற
பதிலைதான் புதியவர்கள் எதிர் பார்ப்பார்கள். அந்த திட்டம் தனது அன்மைகால குறிக்கோளை அடைந்ததா இல்லையா
என்பதை விட அதில் செயல் பாடுமிக்க குழு உள்ளதா என்பதே மிக முக்கியமான கேள்வி.
அந்த இரண்டு விதமான வளர்ச்சி நிலைகள், நிச்சயமாக தொடர்புடையது மேலும் நன்கு அறிமுகம் சேய்ய பட்ட
ஒரு திட்டம் இரண்டையும் பெற்றிருக்கும். தகவல்கள் வேண்டுமானால் முதல் பக்கம் (போதுமான வகையில
இரண்டுவிதமான வளர்ச்சி பற்றிய தகவல்களுடன்) மற்றும் முற்றிலும் உருவாக்குபவர்கள் சார்ந்த பக்கம் இரண்டிலும்
பிரித்து வலங்கப்பட்டு இருக்கலாம்.
உதாரணம்: லாஞ்ச்பேட் நிலைமை குறிகாட்டிகள்
Launchpad.net உருவாக்குபவர்கள் சார்ந்த பக்கம் அமைப்பதை சிற்ப்பாக செய்துள்ளது.
Launchpad.net சற்று வித்தியாசமானது அது மற்ற திட்டங்களுக்கு வளங்கு தளமாகவும் மற்றும்
மற்ற வருக்கு தொகுப்பு சார்ந்த தளமாகவும் உள்ளது(அல்லுது, அத்தகைய திட்டங்களுக்கு குனு/லினக்ஸ்
இயங்கு தளத்தில் தொகுக்க மட்டும் பயன்படுகிறது). எவ்வாரு இருப்பினும் திட்ட ஆரம்ப பக்கம் தானாக
சேகரிக்க பட்ட பல்வேரு குறிகளை திட்டத்தின் நிலைபற்றி புரிந்து கொள்ளும் வகையில் தருகிரது.
இருப்பினும் லாஞ்ச்பேடை அப்படியே பிரதி எடுத்தால் போதுமானது இல்லை —
உங்களி திட்டம் எவை வளர்ச்சி குறிக்கும் காரணிகள் என்பதை மிகவும் சிந்தித்து முடிவெடுக்க
வேண்டும் — ஆயினும் லாஞ்ச்பேட் திட்டம் பல வகையான வாய்புகள் பற்றி
சிரந்த உதாரணமாக உள்ளது. திட்ட பக்கத்தின் துவக்கத்தில் தொடங்கி மற்றும் கீழ் இரங்கி: launchpad.net/drizzle.
அல்லது launchpad.net/inkscape
, இரண்டில் ஒன்றை தேர்ந்தெடுக்களாம்.
வளர்ச்சி நிலை எப்போதும் உண்மையை பிரதிபலிக்க வேண்டும்.
தயாராக இல்லை என்று தோற்றம் தருவதாக பயம் கோள்ள வேண்டாம், மேலும் உயர்த்திகாட்ட
அல்லது மிகைபடுத்தி காட்ட சலனப்பட வேண்டாம். அனைவரும் மேன்பொருள் படிப்படையாக வளரும் என்பதை
அறிவர்; "இது வளர் நிலையில் உள்ள பிழைகள் கொண்ட திட்டம். இது சில நேரம் இயங்காமல் போகலாம்
எனவே ஆபத்தை கவணத்தில் கொண்டு பயன்படுத்துங்கள்" என குறிப்பிடுவதில் தவறேதும் இல்லை. அத்தகைய
வார்தைகள் அந்த சூழலில் தேவைபடும் உருவாக்குபவர் யாரையும் பயம் கொள்ள செய்யாது. பயனர்களை
பொருத்த வரை தார் நிலையில் இருக்கும் முன்பே கவர்ந்திலுக்கும் செயல் மிகவமு தீமையானது. ஒரு முரை
வாங்கிய பின்னர் நிலையற்ற தன்மை அல்லது பிழைகள் இருக்கும் என்ற போதுமதிப்பை மாற்றுவது கடினம்.
பாதுகாப்பு உணர்ச்சி என்றும் பயன் தரும்; பயனர் எதிர்பார்ப்பதை விட அதிகமான
நிலைப்பு தன்மை இருப்பது என்றும் சிரந்தது, மேலும் இன்ப அதிர்ச்சி தரும் வாய்வழி விளம்பரம் என்றும் சிரந்தது.
ஆல்பா மற்றும் பீட்டா
ஆல்பா என்ற சொல் பொதுவாக பயனர்களுக்கு அதை கொண்டு
செயல்கள் செய்யதக்க மற்றும் கண்டுபிடிக்கபட்ட பிழைகள் கொண்டுள்ள முதல் வெளியீட்டை குறிக்கும்.
அதன் முக்கிய நோக்கம் உருவாக்குபவர்கள் எதை செய்ய வேண்டும் என்று கண்டரிய்தக்க விமர்சனம்
பொருவது மட்டுமே. அடுத்த கட்டம் பீட்டா, என்பது அந்த திட்டத்தில்
இருந்த அனைத்து பிழைகளும் கலையபட்டு, பொது வினியோகத்திற்கு வளங்கதக்க வகையில் பல
சேதனைகள் செய்யப்பட வேண்டும். இதன் முக்கிய நோக்கம் பிழைகள் எதுவும் கண்டு பிடிக்க படவில்லை
என்றால்முறைப்படி அருவிக்க பட்ட மென்பொருளாக மாருவது அல்லுத உருவாக்குபவர்களுக்கு நல் விமர்சன்
செய்யபட்டு அவர்கள் அதன் பொது வினியோகம் செய்வதை விரைவு படுத்துவது மட்டுமே. ஆல்பா மற்றும்
பீட்டா இடையில் உள்ள வேற்றுமை என்பது புரிந்து கொள்ளும் தன்மையை பொருத்த்து.
பதிவரக்கங்கள்
அந்த மென்பொருள் கண்டிப்பாக வரையறை செய்யபட்ட வடிவங்களில் பதிவிரக்கம் செய்யும்
படி இருக்க வேண்டும். துவக்க நிலையில், அந்த மென்பொருள் தோகுத்தல் அவ்வலவு கடினம்
இல்லை என்றா இருகூட்டு (இயங்கவல்ல) தொகுப்புகள் அவசியம் அற்றது. (ஆனால்
கடினமானதாகி விட்டால் அது உருவாக்குபவர்களை ஈர்பது மிகவும் கடினமாகிவிடும்!)
வினியோக முரை முடிந்த வரை மிகவும் எளிதாகவும், வரையறை செய்யபட்டும், மேலும்
குறைந்த வேலை பலு கொண்டதாகவும் இருக்க வேண்டும். நோய்க்கு மருந்து வினியாகம் செய்ய
நித்தால் நீங்கள் கண்டிப்பாக ஒரு வரையருக்க பட்டாத அளவுல்ல ஊசி நிர்வகிக்கும் படி வடிவமைக்க
மாட்டீர்கள் அல்லவா. அதைபோல் மென்பொருள் வரையருக்க பட்ட தொகுப்பு மற்றம் நிருவும் முறையை
பயன்படுத்த வேண்டும்; அது எந்த அளவில் வரையறைகளை மீரு கின்றதோ அதே விழுக்காடு பனர்
மற்றும் உருவாக்குபவர்கள் குழப்பம் அடைந்து போவார்கள்.
அது அவசியமாக தோன்றினாலும் பல திட்டங்களில் அது வரைமுரை செய்வதை, எப்போது
வேண்டுமானாலும் செய்துவிடலாம் என்ற நம்பிக்கையில் செய்வதே இல்லை:"நாங்கள்
குறியீடுகள் இருதி நிலை அடையும் தருனத்தில் சரி செய்து விடுவோம்." அவர்கள்
எதை புரிந்து கொள்ள வில்லை என்றால் நேர விரயம் செய்யும் தொகுப்பு மற்றம் நிருவதல் வேலைகளை
தல்லி போடுவதால் திட்டம் நிரைவடைய ஆகும் நேரம் தல்லிபோகும்—ஏன் என்றால் அது
தொகுத்து சோதனை செய்ய முடிந்தால் உதவலாம் என நினைப்பர்களை அதையரியப்படுத்தும். மிக
மெல்லமாக, அந்த திட்டம் அறியாமல் அதன் அனைத்து
உருவாக்குபவர்களையும் தேங்கிய நிகழ்வுகள் காரணமாக இலக்க நேரிடும்: சிலர் திட்ட தளத்தை
அடைந்து மென்பொருள் குறியீடுகளை பதிவிரக்கம் செய்து அதனை தொகுக்க முற்பட்டு தோல்வி அடைந்த
உடன் சென்று விடுவார்கள். அப்படி நடந்ததை அவரை தவிர யாராலும் இனம் காண முடியுமா?
திட்டத்தில் வேலை பார்க்கும் எவருக்கும் நல்ல என்னம் கொண்ட ஒருவர் விலகி சென்றதை கண்டுபிடிக்க
இயலாது.
சோர்வை உண்டாக்கும் மிக முக்கியமான பனிகளை முதலில் செய்துவிடுவது நல்லது, மேலும்
தொகுத்தலில் உள்ள தடைகளை களைவது மிக நல்ல பலனை தரவல்லது.
நீங்கள் தறவிரக்க கூடிய தொகுப்பை வழங்கும் போது, அதற்கு தனிப்பட்ட பதிப்பு எண் கொடுங்கள்,
அதனால் எவரும் ஒப்பிட்டு எது சிறந்தது என்று கண்டுபிடிக்க இயலும். அதன் மூலம் அவர்கள் பிழைகளை
பதிப்பு எண் குறிப்பிட்டு பதிவு செய்ய இயலும்(அது அந்த பிழை ஏற்கனவே தீர்க்கப்பட்டு உள்ளதா என பதில்
கூற இயலும்). பதிப்பு என் பற்றிய மேலும் தகவல்களுக்கு
பகுதியை காண்க, தொகுப்பு மற்றும் நிருவுதலுக்கான தரக்கொள்கை பற்றி மேலும் அறிய
பகுதியை காண்க , இரண்டை
பற்றியும் அறிய பகுதிகளை காண்க.
பதிப்பு கட்டுப்பாடு மற்றும் பிழை கண்காணிப்பானுக்கு அணுகல் அனுமதி
பதிவிரக்கூடிய குறியீடுகளை வளங்குவது நிருவி பயன் படுத்த மட்டும் விரும்புவோர்க்கு வேண்டுமானால்
போதுமானதாக இருக்கும், ஆனால் அது பகுத்தாய்து புதிய அம்சத்தை இனைக்க விரும்புவோர்க்கு போதாது.
இரவு நேர நொடிப்பு எடுப்புகள் உதவியாக இருக்கலாம், ஆனால் அவை வெற்றிகரமான உருவாக்குபவர்கள்
சமூகத்திற்கு தேவையான நுண்ணிய கட்டுப்பாட்டை தற இயலாது. அனைவரும் அந்த தருனத்தில் உள்ள
குறியீட்டை பெற விரும்புவதேடு மேலும் மற்றங்களை பதிவு செய்ய ஒரு வழியையும் விரும்புவர்.
அதர்க்கு தீர்வு பதிப்பு கட்டுப்பாடு செயலி — குறிப்பாக, எதில் இருந்து
அனைவரும் குறியீட்டை தரவிக்கிவும் மாற்றங்களை பெறவும் முடியுமோ அத்தகைய ஒரு இணைய, பகிரங்கமாக
அணுகக்கூடிய பதிப்பு கட்டுப்பாட்டு களஞ்சியமாக இருக்க வேண்டும். பதிப்பு கட்டுப்பாட்டு களஞ்சியம்
—பயனர்கள் மற்றும் உருவாக்குபவர்களுக்கும்—அந்த திட்டம் அனைவரும் பங்களிக்க விரும்பும்
அனைத்தும் தற முயற்ச்சி மேற்கொன்டதர்கு ஒரு குறிப்பு. இதை எழுதும் தருவாயில் பல கட்டற்ற திட்டங்கள்
தடைகள் அற்ற இலவச பொது சேவையாக தள நிருவாகத்தை தரும்GitHub.com-ஐ பயன் படுத்து கின்றன. கிட்ஹப் மட்டுமே
ஒரு தேர்வாகவும், ஒரே சிரந்த தேர்வாகவும், இல்லை என்றாலும் அது பல திட்டங்களுக்கு போதுமானது.
கிட்ஹப், மிகவும் பிரபலமான கட்டற்ற பதிப்பு கட்டுப்பாட்டு மென்பொருள் கிட் செயலியை
சார்ந்து இருப்பினும் அதன் மென்பொருள் கட்டற்றது அல்ல. அப்படி இருக்க வேண்டியது உங்கள் திட்டதிற்கு
அவசியம் தேவையனதா என்பது மிகப்பெரிய கேள்வி, மேலும் அது மிகவும் விரிவாக இல் உள்ள பகுதி
இல் கூர்ப்பட்டுள்ளது. பதிப்பு கட்டுப்பாட்டு
கட்டமைப்பு மிகவும் விரிவாக இல் உள்ள பகுதி
இல் கூரப்பட்டுள்ளது.
அதே தேவைதான் பிழை கண்காணிப்பானுக்கும் உள்ளன. அதன் முக்கியத்துவம் உருவாக்குபவர்களுக்கு
நாளுக்கு நாள் உள்ள பயன் பாட்டில் மட்டும் அல்ல, திட்டத்தை கண்காணிப்பவருக்கும் முக்கிதுவம் வாய்ந்தது.
பலருக்கு, அனுக கூடிய பிழை கண்காணிப்பான் அந்த திட்டதை அவசியமாக எடுத்துக்கொள்ள ஒரு வகையான
குறிப்பு: அதிகப்படியான பிழை எண்ணிக்கை திட்டதிற்கு சிரப்பான தோற்றம் தரும்.
இது எதிர் மாறாக தோன்றலாம், ஆனால் கவனத்தில் கொள்ள வேண்டிது மூன்று முக்கிய காரணிகள் பிழை
எண்ணிக்கையை அதிகமாக காட்டும்: மென்பொருளில் உள்ள உண்மையான பிழைகள் எண்ணிக்கை, பயன்
படுத்துபவர்கள் எண்ணிக்கை மற்றும் பிழைகளை பதிவு செய்ய ஏதுவான தன்மை. மூன்று காரணிகள் இருப்பினும்,
இருதியாக உள்ள இரண்டும் முதலில் உள்ளதை விட மிகவும் சிறப்பானது. எந்த மென்பொருளும் போதுமான
அளவு மற்றும் சிக்கல்கள் கொண்டிருப்பின் அதில் நிரைய பிழைகள் இனம்காண காத்துக்கொணுடு இருக்கும்.
உண்மையான கேள்வி என்ன வென்றால், எத்தகைய வரிசையில் மற்றும் முன்னுரிமை அடிப்படை தரப்பட்டு அவைகள்
தீர்க்கப்படுகின்றன? பெரிய மற்றும் நன்கு கண்காணிக்கபட்ட (அதாவது பிழைகள் எவ்வளவு விரைவில் பதில்
கூரப்படு கிண்றன, எப்படி ஒரே மாதிரியான பிழை பதிப்புகள் கண்டுனர படுகின்றன, மற்றம் பல) பிழை பதிப்பானை
கொண்டுள்ள ஒரு திட்டம் ஒரு பிழைகள் குரைவாக அல்லது கிட்டதட்ட ஒருபிழைகளும் இல்லாத திட்டத்தை விட
சிரந்த உணர்வை தருகின்றன.
உங்கள் திட்டம் ஆரம்ப நிலையில் இருப்பின், கண்டிப்பாக நீங்கள் ஏதும் செய்ய இயலாது. ஆனால் திட்ட
நிலை பக்கம் திட்டத்தின் அதன் ஆரம்ப நிலையை விளக்கமா சொல்லி, மேலும் பிழைபதிவுகள் மிக அன்மையில்
பதிய பட்டிருப்பின், பார்ப்பவர்கள் அந்த திட்டம் ஆரோக்கியமான விகித்தில் பதிய
பட்டுள்ளதை கவணித்தால் குறைவான பிழைகள் பற்றி கவலை கொள்ள மாட்டார்கள்.பிழை
பதிப்புகள் நல்லது என்பது பற்றி மேலும் அறிய, காண்க
rants.org/2010/01/10/bugs-users-and-tech-debt, நான் 2010ல் எழுதிய பதிவு எப்படி
பிழை பதிவு தவரில்லை ஆனால் வளர்ச்சி அரிகுறி என்று கூருகிறது என
"தொழில்நுட்ப கடன்
"-ல் காண்க.
கவணிக்க வேண்டியது பிழை கண்காணிப்பான் பிழைகளை குறிக்க மட்டும் இன்றி, விரிவாக்க கோரிக்கைகள்,
ஆவண மாற்றங்கள், நிலுவையில் உள்ள பணிகள் மற்றும் பல வேலைகளை செய்கின்றன. பிழை கண்காணிப்பான்கள்
இயக்கும் முரை பற்றிய விவரங்கள் அறிய இல் உள்ள பதிவை
காண்க. எனவே அவற்றை இங்கு விவரிக்க போவது இல்லை. அரிமுகம் சேய்யும் நோக்கில் பிழை கண்காணிப்பான்
ஒன்றை பெற்றிருக்க வேண்டுதம், மேலும் அது முதல் பக்கத்தில் இருந்து அடையும் படி
தர வேண்டும்.
தகவல் தொடர்பு தடங்கள்
பொதுவாக எவரும் ஒரு திட்டதில் ஈடுபட்டுள்ளோரை எவ்வாரு தொடர்பு கெள்வது என அறிய விரும்புவர்.
அஞ்சல் பட்டியல்கள், மின்னாடல் அறைகள், ஐஆர்சி தடங்கள் ()
மற்றம் ஏனய தடங்களை உருவாக்கி திட்ட பங்காளர்களுக்கு தொடர்புக்கு வழி செய்து தாருங்கள். நீங்களும் மற்ற திட்ட
நிருவுனர்களும் அந்த அஞ்சல் பட்டியல்களில் சந்தா பெற்று இருக்க வேண்டும், அதனால் உருவாக்குபவர்களை தொடர்பு
கொண்டு கருத்து கூர வழி இருப்பதை அனைவரும் உணர்வார்கள். நீங்கள் சந்தா பெற்று இருப்பதால் அனைத்து
கேள்விகளுக்கும் பதில் அளிக்கவும் அனைத்து கோரிக்கைகளையும் நிருவுவதர்க்கும் உதிரவாதம் தரவேண்டிய அவசியம்
இல்லை. நீன்ட நாள் இக்கத்திர்கு பின்னர், மிக குறைவானவர்களே கருத்துக்களம் பயன்படுத்துவர், ஆயினும் தேவை
இருப்பின் பயன் படுத்தி முடியும் என்று அனைவரும் அறிவர்.
திட்டதின் துவக்கத்தில் உருவாக்குபவர்கள் மற்றும் பயனர்கள் இருவருக்கும் தனித்தனி கருத்துக்களம் இருக்க
வேண்டிய அவசியம் இல்லை. அனைவரும் ஒரே "அறையில்" விவாதிப்பது அப்பொழுது மிகவும் ஏற்றதாக இருக்கும்.
ஆரம்பத்தில் பங்குகொள்வோர் மத்தியில், மேம்பாட்டாளர் மற்றும் பயனர் இடையே வேறுபாட்டு பெரும்பாலும் தெளிவில்லாமல்
இருக்கிரது; காரணம் துவக்கத்தில் பாகுபாடு செய்யமுடியாத அளவிற்கு, உருவாக்குபவர்கள் மற்றும் பயனர்களுக்கு இடையே
ஆன விகிதம் மிக அதிகமாக இருக்கிறது. நீங்கள் ஆரம்ப காலதில் பங்கு பெருவோர் கண்டிப்பாக உருவாக்குபவராகள்
என்று என்ன இயலாது, ஆயினும் அவர்கள் உருவாக்குபவர்களின் விவாதத்தில் பங்கு கொண்டு திட்டம் எந்த திசையில்
செல்கின்றது என்று அறிந்து கொள்ள விரும்புவதாக கருதலாம்.
இந்த அத்தியாயம் திட்டத்தை துவங்குவதை பற்றி மட்டுமே விளக்குவதால், தகவல் தொடர்பு தடங்கள் இருக்க
வேண்டும் என்று மட்டமே கூருவது போதுமானது. பின்பு இன்
இல் அதர்க்கான நேரம்
வருகையில் எவ்வாறு இருக்க வேண்டும், எப்படி வடுவமைக்க வேண்டும், எத்தகைய கட்டுப்பாடு அல்லது மற்ற மேலாண்மை
இருக்க வேண்டும், மற்றும் எப்படி உருவாக்குபவர்கள் மற்றும் பயனர்கள் கருத்துக்களம் இடையே எத்தகைய வித்தியாசம்
இருக்க வேண்டும் போன்ற வற்றை நாம் விவாதிக்கலாம்.
உருவாக்குபவர்களுக்கான வழிமுறைகள்
எவரேனும் பங்களிக்கி விரும்பினால், அவர் உருவாக்குபவர்களுக்கான வழிமுறைகள் என்ன என்பதை பார்க்க
விரும்புவார்கள். அது அதிகம் தொழில்நுட்பம் சார்ந்தது இல்லாமல் சமூக வழிமுரை சார்ந்த்து: அவை எவ்வாரு
உருவாக்குபவர்கள் தங்களுக்குள் மற்றன் பயனர்களுடன் எப்படு தொடர்பு கொண்டு இருதியாக செயல்களை எப்படி
முடிவுக்கு கொண்டு செல்ல வேண்டும் என்பதை பற்றியது.
அந்த தலைப்பு முலு விலக்கத்துடன் என்ற
இல் இருக்கும் பகுதியில் கூரப்படுள்ளது,
ஆயினும் அதன் அடிப்படை கூருகள்:
மற்ற உருவாக்குபவர்களுடன் தொடர்பு கொள்ள இருக்கும் சுட்டிகள்
பிழைகள் மற்றும் மாற்றம் செய்ய பட்ட திட்டுகளை எப்படி சமர்ப்பிப்பது
எப்படி மேம்பாடு செய்யப்படுகின்றது
மற்றும் முடிவுகள் எடுக்கபடு கின்றது என்ற சிரு குறிப்பாக—அது தாராளமனதுடன் கூடிய
சர்வாதிகாரமா, ஜனநாயகமா, அல்லது வேரு ஏதோ ஒன்றை பின் பற்றுகிரதா என்னும்
வகையில்.
"சர்வாதிகாரமா" என்பது எந்த ஒரு இழிவுபடுத்தும் வகையிலும் இங்கு குறிப்பிடப்பட வில்லை. இதில் ஒரே ஒரு
உருவாக்குபவர்கு மட்டும் அனைத்து நிராகரிக்கும் அதிகாரத்தையும் கொடுத்து திட்டத்தை நடத்தி செல்வது எந்த தவரும்
இல்லை. பல வெற்றி கரமான திட்டங்கள் அவ்வாரு இயங்கு கின்றன. அதில் முக்கியமான ஒன்று அவை அவ்வாரே
உருவாக்க பட்டு மேலும் அவ்வாரு இருக்கும் என்பதை குறிப்பிட்டும் வெளிவரு கின்றன.
ஒரு கொடுங்கோன்மை ஜனநாயகம் போல் பாசாங்கு செய்வதை மக்கள் விரும்ப மாட்டார்கள்; அதே பொல்
கொடுங்கோன்மை என்பதை குறிப்பிட்டு அதன் சர்வாதிகாரி நம்பகத்தன்மையுடனும் தகுதியுடனும் இருப்பின் திட்டம்
எந்தவித தங்கு தடையும் இன்றி தொடரும்(
பகுதியில் உள்ள
விளக்கத்தில் மேலும் எப்படி இங்கு சர்வாதிகார்ம் என்பது மற்ற துரைகளை காட்டிலும் மாருபட்டது என்பதை
காணலாம்.)
subversion.apache.org/docs/community-guide ஒரு சிரந்த உருவாக்குபவர்களுக்கான
விதிமுறைகள் அமைத்து தந்து உதாரணமாக உள்ளது;
wiki.documentfoundation.org/Developmentஇல் கொடுக்கப்பட்டுள்ள லிப்ரெ ஆபிஸ்
விதிமுறைகளும் சிறந்த உதாரணம்.
இந்த அத்தாயாயத்தின் பிற்றபகுதியில் உருவாக்குபவர்களுக்கு வளங்கப்பட வேண்டிய அறிமுகம் குறித்து
என்ற பகுதியில் விளக்க பட்டுள்ளது.
ஆவணங்கள்
ஆவணங்கள் மிகவும் அவசியமானவை. எளியவையாக மற்றும் முழுமையடையாது இருப்பினும்
சில ஆவண்ங்கள் பயனர் படிக்கும் படி இருக்க வேண்டும். இது முன்பு
குறிப்பிட்டது போன்று "வேலைப்பளு" கொண்டது, ஆயினும் இதில் தான் பல கட்டற்ற திட்டங்கள் கீழே
விழுகிறன. குறிக்கோள் விளக்கம், அம்சங்கள் பட்டியல், உரிமம் தேர்வு செய்தல், வளர்ச்சி நிலை
சுருக்கம் ஆகிவை செய்த பிரகு—இவை அனைத்தும் மிக சுலபமானவை, அவை கண்டிப்பாக ஒரே
ஒரு முரையில் செய்து முடிக்க வேண்டியவை, அதன் பின்பு மீன்டு அதை பற்றி கவலை பட வேண்டியது
இல்லை. ஆவணங்கள் அப்படி பட்டவை இல்லை, அது என்றும் நிறைவு பெற்றதாக என்ன இயலாது,
அதனாலோ என்னவோ அதை துவள்க பலர் காலதாமதம் செய்கின்றனர்.
அதில் மிகவும் வஞ்சகமான காரியம் என்ன வென்றால் ஆவணங்கள் தயாரிக்க தேவைப்படும் கருவிகள்
அதை படிக்க தேவைப்படுவதை விட முற்றிலும் மாரு பட்டது. பிதிவர்களுக்கான ஆவணமே அதில் மிக
முக்கியமானது: எப்படி மென்பொருளை நிருவுவது, எப்படி அது இயங்குகிறது மேலும் சில செயல்களை எப்படி
செய்வது என்ற வரைமுரை ஆகியவை. ஆயினும் இவை அனைத்தையும் எழுதுபவர்
எதுபவர் எத்தகைய எளிமையாக செய்கிராரோ—அதை எழுதுவது அத்தகைய கடினமானது படிப்பவர்
பக்கம் இருந்து சிந்திப்பது, மேலும் சிரம்ப்பட்டு அனைத்து வழிகளையும் தருவது (எழுதுபவருக்கு) தேவையற்றது
வேலை போல் தோன்றும்.
அதை தீர்க்க எந்த ஒரு மந்திர சாவியும் கிடையாது. சிலர கண்டிப்பாக அமர்ந்து எழுதிமுடிக்க
வேண்டும், மேலும், முக்கியமாக, படிப்பவர்களின் கருத்துக்களை ஏற்றவாரு இனைக்கவும் வேண்டும். எளிய
முரையில் எழுதவும் வடிவமைக்கவும் உதவும் HTML, உரை வடிவம், Markdown, ReStructuredText,
அல்லது XML மாற்று வடிவங்களை பயன்படுத்துக—எளிய முரையில் மாற்றம் செய்யது வளப்பத்த
கூடியதாகமுதல் முரையே சரியான வடிவமைப்பை தேர்வு செய்ய கவலை பட வேண்டாம்.
நீங்கள் உங்கள் முடிவை மாற்ற நினைத்தால், அதை தானியங்கி முரையில்Pandocஐ பயன் படுத்தி மாற்றி
விடலாம்.. இது எழுதுபவருக்கு தொடர்ந்து மேன்மை படுத்த அதில் உள்ள
சிரமத்தை மட்டும் தீர்க்காமல், பின்பு ஆவணப்படுத்த முன்வருபவருக்கு பயன் படும்.
ஆவணத்தின் எல்லையை துவக்கத்தில் சற்று குரைத்துவைப்பது அதை செய்து முடிப்பதை
உருதி செய்யும். அப்படி செய்வது குறைந்த பச்சம் முடிவற்ற வேலை போன்று தேன்றாது. அதில் உள்ள
அடிப்படை விதி குறைந்தது பின்வரும் நிபத்தனைகளை நிரைவு செய்வது தான்:
படிப்பவருக்கு எத்தகைய அடிப்படை அறிவு அவசியம் என்பதை தேளிவு படுத்துக.
மிகவும் தெளிவாக மற்றும் விளக்கமாக எப்படி அந்த மென்பொருளை நிருவது
என்பதுடன் துவக்கத்தில் எங்கேனும் எப்படி பழுதரியும் சோதனையை இயக்குவது அல்லது
சரியாக நிருவியதை உறுதி செய்யும் கட்டளை ஏதேனும் இருப்பின் அதை இயக்கும்
முறைபற்றியும் குறிப்பிடவும். ஆரம்ப ஆவணம் பொதுவாக பயன்படுதும் வழிமுறை
ஆவணத்தைவிட சற்று முக்கியமானது. நிருவுதல் மற்றும் துவங்கும் முறைபற்றி அறிந்து
கொள்ள ஒருவர் அதிக நேரம் செலவிட நேர்ந்தால் அவர் மிகவும் மேம்பட்ட
இயக்கங்களுக்கான பகுதியும் அப்படி கடினமாக இருக்கும் என்று என்ன அதிக வாய்ப்பு
உள்ளது. கைவிட்டு செல்ல விரும்புவோரில் துவக்கத்திலேயே விட்டு விடுவார்கள்தான் அதிகம்
எனவே நிருவுதல் போன்ற, ஆரம்ப விஷயங்கள், மிகவும் கவணத்துடன் சொல்லப்பட
வேண்டும்.
ஒரு பொதுவான செயலை எப்படி செய்வது என்று ஒரு பயிற்சி போன்ற உதாரணம்
கொடுக்க வேண்டும். கண்டிப்பாக பலவகையான உதாரணங்கள் தருவது மிகவும் சிரந்த்து
இருப்பினும் நேரம் இல்லை என்றால் ஒன்றை மட்டும் தேர்வு செய்து மிகவும் தெளிவாக
விளக்கம் தாருங்கள். ஒருவர் அதை படிக்கும் போது அந்த மென்பொருள் ஒரு செயலை
எப்படி செய்கிறது என புரிந்து கொண்ட உடன் மற்ற செயல்களை
எப்படி செய்கிறது என்று தானகவே காண முயல்வார்கள்—மேலும் நீங்கள்
அதிஸ்டசாலியாக இருப்பின் அவர்களாகவே அவைகளை ஆவணப்படுத்த விரும்புவார்கள். அது
நம்மை அடுத்த நிபந்தனைக்கு இட்டு செல்கிரது...
எங்கெல்லாம் ஆவணம் முடிவடையாமல் இருக்கின்றது என்று குறித்து வையுங்கள்.
அதனால் அதில் நீங்கள் முடிக்க முடியாமல் போனவற்றை சுட்டிகாடி,
அவர்களுடன் கருத்து ஒற்றுமை அடைய முடியும். உங்கள் பச்சாத்தாபம் அவர்களை நீங்கள்
எதற்கு முக்கியதுவம் தந்தீர்கள் என இனம்கான உதவும். அந்த குறிப்புகளுடன் பின்
தேதியிட்டு அதர்குள் முடிக்க விருப்பதாக அறிவிக்க வேண்டும்—அது உதவி
தேவைபடுவதை முறைப்படி அறிவிப்பது போன்றது.
அந்த கடைசி நிபந்தனை மிகவும் முக்கியமானது, உண்மையில், அது அந்த திட்டம் முலுவதிர்க்கும்
உதவி தேவைப்படுவதாக நினைப்பை கொடுக்கும். துல்லியமாக குறைகளை குறித்து வைப்பது கட்டற்ற
மென்பொருள் திட்டங்களின் ஒரு முக்கிய விதி. தயவுதாட்சணை இல்லாமல் மற்றும் உணர்ச்சி வசப்படாமல்
சரியன வற்றை மட்டம் இனம் கண்டு குறித்து வையுங்கள் அதில் எந்தவித மிகைபடுத்துதலும் இல்லாமல் இருப்பது
அவசியம்(ஆவணங்கள், பிழை குறிப்புகள் அல்லது அஞ்சல் பட்டியல்கள் போன்ற அனைத்திலும்
அவ்வாரு இருக்க வேண்டும்). அந்த திட்டமே வெளிப்படையாக சொல்ல வில்லை என்றால் அதனை எவரும் ஒரு
திட்ட தோல்வியாகவோ அல்லது குறிப்பிட்ட தேதியில் தீர்க்க தறப்பட்ட உருதியாகவோ கருத
மாட்டார்கள். எனவே அந்த திட்டத்தை பயன்படுத்வேர் எவரும் அதன் குறைபாட்டை அறிந்திருப்பதால்
அதர்கு மனதலவில் தயாராகவும் இருப்பர்—எனவே அந்த திட்டம் அதன் அடிப்படை அறிந்து
செயல் படுவதை போன்று இருக்கும்.
அடிக்கடி கேட்கப்படும் கேள்விபதில்களை பராமரித்தல்
அடிக்கடி கேட்கப்படும் கேள்விபதில்களை("FAQ") பராமரிப்பது ஒரு
திட்டத்தின் பயிற்றுமுரை பயன்பாட்டிற்கு பேருதவியாக இருக்கும். பொதுவாக உருவாக்குபவர்கள் மற்றும்
பயனர்கள் கேட்க விரும்பும் கேள்விகளுடன் ஒருங்கினைந்து இருக்கும் படி கேள்விபதில்கள் அமையவேண்டும்
—நீங்கள் எதிர்பார்கும் கேள்விகளுக்கு அல்ல—எனவே நன்கு
நிர்வகிக்க பட்ட கேள்விபதில்கள் அதனை பரிசீலனை செய்பவர்களுக்கு தேவையானது கிடைக்கும் படி
இருக்கும். பொதுவாக பிரச்சனைகள் உருவாகும் போது பார்கப்படும் முதல் பக்கம் கேள்விபதில்கள்தான்,
சில சமயம் அதிகார பூர்வமான கையேட்டை விட கேள்விபதில்கள் சிரந்த தேர்வாக இருக்கும், மேலும் மற்ற
தளங்களில் இருந்து உங்கள் தளதுடன் இனைக்க பட்டு இருக்கும் பொதுவான பக்கமும் இதுவாக தான்
இருக்கும்.
நீங்கள் திட்டத்தின் துவக்கத்தில் கேள்விபதில்களை உருவாக்க முடியாதது இதில் வருந்ததக்கது.
நல்ல கேள்விபதில்கள் எழுதப்பட்டவை அல்ல அவை தானாக வளர்தவை. அதன் வரையறை படி அது
எதிர்வினை ஆவணம், அந்த மென்பொருள் பற்றி பலரும் கேட்ட கேள்விகள் கொண்டு வளர்ந்து வந்தது.
எனவே அவர்கள் என் கேட்பார்கள் என்று சரியாக எதிர் பார்க்க முடியாது, எனவே அதனை ஆரம்பம் முதல்
சிந்தித்து எழுத முடியாது.
எனவே அதை செய்ய நினைத்து உங்கள் நேரத்தை வீன் செய்யாதீர்கள். ஆயினும் ஒரு பக்கத்தில்
அதர்க்காக சில மாதிரி கேள்விகள் அமைத்து வைப்பதில் தவரேதும் இல்லை, எனவே திட்டம் நடைபெரும்
பொழுது அதில் சிலர் தங்கள் பங்களிப்பை செய்வார்கள். அந்த தருனத்தில், மிக முக்கியமான விதி அது
முலுமையாக இருக்க வேண்டும் என்பது அல்ல மாறாக எளிமையாக புதிதாக
செர்க்கும் படி உள்ளதா என்பதாகும். (சரியான கேள்விபதில்கள் பக்கம் என்பது சிறிய அம்சம் கிடையாது
அதை பற்றி மேலும் விவரங்கள் இன்இல் உள்ளது. மேலும் ஐ காண்க.)
ஆவணங்கள் வளங்கப்படுவது
ஆவணங்கள் கண்டிப்பாக இரண்டு இடங்களில் வளங்கப்பட வேண்டும்: இனையத்தில் (இனைய
தளத்தில் நேரடுயாக), மற்றும் பதிவிரக்க கூடிய மென்பொருள் வினியோகத்துடன்
(பார்க்க இன்
பகுதியை). அது இனையத்தில், உலாவும் படி,
கிடைக்க வேண்டும், ஏன் என்றால் மக்கள் பொதுவாக மென்பொருள் பதிவிரக்கும்
முன்பு அதன் ஆவணங்களை முதலில் படிக்க விரும்புவார்கள், அது அவர்களுக்கு
பதிவிரக்கம் தேவையா இல்லையா என முடிவு செய்ய உதவியாக இருக்கும். ஆயினும் அது பதிவிர்க்க படும்
மென்பொருளுடனும் இருக்க வேண்டும், ஏனென்றால் பதிவிரக்கம் அனைத்தையும்
தொகுத்து தர வேண்டும் (அதாவது உள்ளமைவாக அணுக) என்னும் அடிப்படைக்காக.
இனைய ஆவணங்களில், முலு ஆவணத்தையும் ஒரே HTML
பக்கமாக தரவள்ள ஒரு இணைப்பை நிச்சயம் இருக்கும் படி செய்க ("ஒன்றுபட்ட ஒற்றை பக்கத்தில்" அல்லது
"அனைத்தும் ஒரே பக்கத்தில்" அல்லது "ஒற்றை பெரிய பக்கமாக" பேன்ற குறிப்பை அதன் அருகிள் அமைத்து
விடுங்கள்). இது பொதுவாக மக்கள் ஒரு செல்லை முலு ஆவணத்திலும் தேட ஏதுவாக இருக்கும்.
பொதுவாக அவர்கள் தேடுவது என்ன வென்று நன்கு அறிவார்கள் ஆயினும் அது எந்த பாகத்தில் உள்ளத் என
தேட முற்ப்படுவார்கள். அப்படி பட்டவர்களுக்கு ஒரு HTML பக்கத்தில் பகுதி அட்டவனை, அடுத்ததில் அறிமுகம்,
அடுத்ததில் நிருவும் முரை என வரிசை படுத்தி வைத்திருப்பது மிகவும் சிரமம் தரக்கூடிய செயல்.
அப்படி பக்கங்களாக பிரித்து வைக்க பட்டிருப்பது அவர்களின் உலாவியின் தேடு பொறி பயன் அற்றது. அந்த
முறை எந்த பகுதியை வாசிக்கின்றோம் என்று அறிந்தவர் மற்றும் ஆரம்பம் முதல் இருதி வரை படித்து முடிக்க
விரும்புவோர்க்கு ஏற்றதாக இருக்கும். ஆனால் அப்படி அனுகுவது பொதுவான முறை அல்ல. மேலும்,
மென்பொருள் பற்றி அறிந்த ஒருவர் ஒரு குறிப்பிட்ட செல் எந்த பகுதியில் உள்ளது என காண முற்படுவதே
பொதுவானது, எனவே அப்படி பட்ட ஒற்றை பக்க ஆவணம் தராமல் இருப்பது அவர்களுக்கு மிகவும்
வெருப்பை தூன்டும்.
உருவாக்கு பவர்களுக்கான ஆவணங்கள்
உருவாக்குபவர்களுக்கு மற்றொரு உருவாக்குபவர் குறியீடுகளை சரி செய்து விரிவாக்க அவசியம் புரிந்து
கொள்ள வேண்டுவதை எழுதுவது. இது முன்னர் கூரப்பட்ட அதிகம் சமூக சிந்தனையில் கொடுக்கப்படும்
உருவாக்குபவர்கள் வழிகாட்டியில் இருந்து வேரு பட்டது. அது உருவாக்குபவர்கள் எப்படி
இணைந்து செயல் படலாம் என சொல்கிறது; உருவாக்கு பவர்களுக்கான ஆவணம் அதன்
குறியீட்டுடன் எப்படு இணைந்து செயல் படலாம் என சொல்கிறது. இவை இரண்டும் பொதுவாக வசதிக்காக
ஒரே ஆவணத்தில் தரப்படுவது உண்டு (
subversion.apache.org/docs/community-guide உதாரணத்தில் உள்ளது போல்), ஆனால்
அப்படி இருக்க வேண்டிய கட்டாயம் இல்லை.
உருவாக்கு பவர்களுக்கு ஆவணம் அவசிம் என்றாலும் அதை எழுதி முடிக்க எந்த வெளியீட்டையும்
தள்ளிப்போட வேண்டியது இல்லை. அந்த மென்பொருள் உருவாக்கியவர்கள் பதிள்கள் கூற (பதில்
கூர விருப்பதுடனும்) இருப்பின், அதுவே போதுமானது. மீன்டும் மீன்டும் ஒரே மாதிரியான கேள்விகளுக்கு
பதில் கூர நேர்வதே ஆவணம் எழுத தூனுடுதலாகவும் இருக்கும். அது எழுதப்படும் முன்பாகவே, ஆர்வம்
மிகுந்த உருவாக்கு பவர்கள் குறியீடுகள் தெளிவு பெற்று விடுவார்கள். அவர்களுக்கு உதவும் படி ஏதேனும்
செயல்பாடு அதில் இருப்பதே அதனை கற்று கொள்ள தூண்டும் காரணியாக இருக்கும். அதன் மீது நம்பிக்கை
இருக்கும் போது, அதை கண்டு பிடிக்க அவர்கள் நேரம் ஒதுக்குவார்கள்; அவர்களுக்கு நம்பிக்கை வராவிடில்,
எந்த ஒரு ஆவணமும் அவர்களை பெரவும் அல்லது நிலை நிருத்த உதவாது.
எனவே உங்களுக்கு ஒரே ஒரு வகையான வடிக்கையாலருக்கு மட்டும் ஆவணம் எழுத நேரம் இருப்பின்,
பயனர்களுக்கானதை எழுதுங்கள். அனைத்து பயனர் ஆவணங்களும், பிரதி பலனாக, உருவாக்கு பவர்களின்
ஆவணங்களே; எந்த ஒரு செயல் முறையிலும் மேன்படுத்த முற்ப்படும் முன்பு அவர்கள் அதை பற்றிய பயன்
பாட்டு அறிவு பொற்றிருப்பது அவசியம். பின்னர், ஒரே ஒரு வகையான கேள்விகள் மீன்டும் மீன்டும் கேட்கப்படின்
ஒரு தனிப்பட்ட ஆவணம் உருவாக்க முயற்சி செய்யலாம்.
சில திட்டங்கள் விக்கியை ஆரம்ப அல்லது முக்கிய ஆவணமாக பயன் படுத்து கின்றன. எனது
அனுபவத்தில், அது ஒரு சிலரால் தீவிரமாக நிருவகிக்க பட்டு அதன் "குறல்" எப்படி இருக்க
வேண்டும் முடிவு செய்ய பட்டு இருந்தால் சிறப்பான பலன் தர கூடியது. மேலும் தகவளுக்கு
இன்
பகுதியை பார்க்க.
செய்முறைகள், திரைப்பிடிப்புகள், வீடியோக்கள், மற்றும் எடுத்துக்காட்டாக வெளியிடல்
அந்த திட்டம் வரைகலை பயனர் இடைமுகம் கெண்டு இயங்கினால், அல்லது வரைகலை வெளியீடு
செய்தால் அல்லது மாறுபட்ட வெளியீடு உருவாக்கினால், சில திரைப்பிடிப்புகளை திட்ட தளத்தில் இனைத்து
விடுங்கள். இடைமுகம் இருப்பின், திரைப்பிடிப்பு அல்லது, அதைவிட சிரப்பான, குறுகிய (4 நிமிடங்களுக்கு
குறைவான) வீடியோ வழிகாட்டலுடன் அல்லது வசனத்துடன் இருக்க வேண்டும். வெளியீடுகளுக்கு, அது
திரைப்பிடிப்பு அல்லது பதிவிரக்க கூடிய மாதிரி கோப்புகளாக இருக்கலாம். இனையம் சார்ந்ததெனில், அந்த
மென்பொருள் ஏதுவானது இருப்பின், தங்கத் தரநிலை ஒரு உதாரண தளம் இருப்தே ஆகும்.
அதில் முகியமானது அவர்கள் மனநிரைவு அடையும் படி விர்பத்தை தீர்க்க வேண்டியதை தர வேண்டும்.
ஒரு திரைப்பிடிப்பு அல்லது வீடியோ பல பத்திகளின் மற்றும் அஞ்சல் பட்டியலில் உள்ள விளக்கத்தை காட்டிலும்
எளிதில் திருப்தி படுத்தும் படி இருக்கும், ஏன் என்றால் அது மென்பொருள் இயங்க கூடுயது
என்பதை நிரூபனம் செய்கிறது. அதன் குறியீடுகளில் பிழைகள் இருக்கலாம், அதை நிருவது
கடினமாக இருக்கலாம், அது முற்றிலும் ஆவணப்படுத்த படாமல் இருக்களாம் ஆனால் ஒரு நிரூப்படம் அதை
சற்று சிரமம் மேற்கொண்டால் இயக்க இயலும் என உருதி செய்கிரது.
வீடியோவை சுருக்கமாக அமைத்து, அதை சுருக்கமானது என்று
குறிப்பிடுக
நீங்கள் வீடியோ விளக்கப்படம் உங்கள் திட்டத்தில் கொடுத்து இருந்தால், அதை 4 நிமிடத்துக்குல்
இருக்கும் படி அதன் ஓடும் நேரத்தை அதை இயக்காமலேதெறிந்து கொள்ள
வசதியாக குறிப்பிட்டு தருக. இது முன்னர் கூறியது போல் "அளவிட பட்ட அறிமுகம்" என்ற கொல்கையை
சார்ந்தது: நீங்கள் அப்படி செய்வதால் அதனை காண முடிவு செய்வதை அனைத்து தடைகளுயும்
நீக்கி எளிதாக்கலாம். பயனர்கள் "எங்கள் 3 நிமிட வீடியோவை பாருங்கள்" என்ற இனைப்பை
"வீடியோவை பாருங்கள்" என்று கூரும் இனைப்பை விட அதிகமாக விரும்பும் வாய்ப்பு உள்ளது ஏன் என்றால்
தாங்கள் எதை செய்ய விருக்கிரோம் என்பதை அதன் சுட்டியை இயக்கும் முன்பே செய்யும் முன்பே தெறிந்து
கொள்வதால் — அதை அவர்கள் மனதலவில் தயாராகி செய்வதால் நன்றக பார்கவும்
செய்வார்கள், அப்படி இல்லாம் பாதியில் சோர்வடைந்து நிருத்த மாட்டார்கள்.
அந்த 4 நிமிட நிபந்தனை எப்படி உருவானது: அது ஒரு ஆய்வின் முடிவு, ஒரே (பெயர் குறிப்பிட
விரும்பாத நபரை பலமுறை திட்ட வீடியோக்களை பார்க்க செய்து முடிவு செய்ய பட்டது. அது மற்ற
செயல்முறை விளக்கப்படம் அல்லது வழிகாட்டும் வீடியோக்களுக்கு பொருந்தாது.
ஒரு வேளை நிங்கள் முன்னதாகவே இடைமுக வீடியோ பதிவு செய்யும் செயலி ஒன்றை தேர்வு
செய்யாமல் இருந்தால்: எனக்கு நல்ல அதிர்ஷ்டமாக இருந்த டெபியன் குனு/லினக்ஸ் இல்
இயங்கும் gtk-recordmydesktop, மற்றும் பிறகு
OpenShotஐ வைத்து வீடியோ திருந்தியை கொண்டு மாற்றி எழுதலாம்
நேரம் இருப்பின், நீங்கள் இன்னும் பல தகவள்களை உங்கள் திட்ட பக்கத்தில் வளங்களாம், அல்லது
ஒன்று அல்லது பல காரணங்களுக்காக தேவைக்கேர்ப்ப தரலாம்: ஒரு செய்தி பக்கம், ஒரு திட்ட வரளாரு
பக்கம், ஒரு தொடர்புடைய இனைப்புகள் பக்கம், ஒரு முலு தளதிலும் தேட வள்ள பொறி, ஒரு நன்கொடை
பக்கம் போற்று ஏனையவை அனைத்தும். அவை எதுவும் துவக்கத்தில் அவசியம் அற்றவை இருப்பினும்
வருங்காலத்தில் செய்யும் படி கவணத்தில் வைக்திருங்கள்.
ஓம்புதல்
இணையத்தில் எங்கு உங்கள் திட்ட மூலப்பொருள்களை வைப்பது?
நிச்சயமாக ஒரு வலைத்தளம் — ஆயினும் அதல் முலு விளக்கம் சற்று குழப்பமானது.
பல திட்டங்கள் தங்கள் பொது பயனர் வலைத்தளத்தை—
அழகான படங்கள், முன்னொட்டம், வீடியோக்கல், வழி நடத்தப்பட்ட தள சுற்றுலாக்கள் மற்றும்
பல துனுக்குகள் வைத்து ஒரு தனி தளமாக — மிகவும் நுன்னிய மற்றும் முலுவதும்
மோனோஸ்பேஸ் எழுத்துகளில் போலித்தனைமயை அல்லாத சுருக்கங்களுடன் உள்ள உருவாக்கு பவர்களுக்கான
தளத்தில் இருந்து வேறுபடுத்தி காட்டு கின்றன.
சரி, நான் மிகைப்படுத்து கின்றேன். ஒரு சிறிய அளவில். எப்படி இருப்பினும், திட்ட ஆரம்
காலங்களில் நீங்கள் அப்படி பட்ட வேருபாட்டை தர அவசியம் எதுவும் இல்லை. அச்சமையங்களில் உங்கள்
திட்டத்தை பார்வையிடுபவர்கள் மேம்படுத்து பவர்களாகவோ அல்லது குறைந்த பச்சம் புதியதை முயற்சி செய்ய
பலக்கியவர்களாகவும் இருப்பார்கள். காலம் செல்ல செல்ல அவர்களில் பலர் சிரிதளவாவது திட்ட
மேன்பாட்டில் ஈடுபட விரும்பினால்(நிச்சயமா, உள்ளகள் திட்டம் ஒரு குறியீட்டு நூலகமாகவும், அதன்
"பயனர்கள்" மற்றொரு உருவாக்குபவராகவும் இருக்கலாம்), பயனுருக்கான தனியான தளத்தை
அமைக்க வேண்டிய அவசியத்தை நீங்களாக உணர்வீர்கள். ஒத்துழைப்புடன் இயங்கும் தளம் குறியீட்டு களம்,
பிழை கண்கானிப்பான், உருவாக்குபவர்கள் விக்கி, உருவாக்கு பவர்களில் அஞ்சல் பட்டியல் இனைப்புகள்
மற்றும் பலவற்றை கொன்டிருக்கும். அந்த இரண்டு தளங்களும் ஒனுறுடன் ஒன்று இனைந்து இருக்க
வேண்டும், முக்கியமாக பயனர் தளம் இது ஒரு கட்டற்ற திட்டம் மற்றும் மேன்படுத்தும் செயல்பாடு இருக்க
முடியும் என்பதை குறிக்க வேண்டும்.ஆகஸ்டு 2013 வரை, குறுக்கு இனைப்புகள் கொன்டு
ஒரு தனித்து இயங்க்கும் பயனர் மற்றும் மேம்பாட்டள்கள் தளங்களில் உதாரணமாக உள்ளது Ozone Widget
Framework:அதை ozoneplatform.org அவர்களில் பயனர்
தளத்தை
github.com/ozoneplatform/owfஇல் உள்ள மேம்பாட்டளர் தளத்துடன் ஒப்பிட்டு
காண்க.
கடந்த காலங்களில், பல திட்டங்கள் மேம்பாட்டாள்ர்கள் தளத்தை அவர்களாகவே உட்கட்டமைப்பு
செய்து வளங்கி வந்தனர். ஆயினும், கடந்த பத்தாண்டுகளில், பல கட்டற்ற மென்பொருள்கள் — கிட்ட தட்ட புதியவைகள் அனைத்தும் —
இலவசமாக கட்டற்ற மென்பொருள்களுக்கு என்று "தொகுக்க பட்டு வளங்கும்" தளங்களை பயன் படுத்தி வளங்க படுகின்றன. இதுவரை அதில் மிகவும் வெற்றகரமானது,
GitHub.com, மேலும் உங்களுக்கு என்று எந்த வித தேர்வும் இல்லை என்றால் நீங்கள் கிட்ஹப்
தேர்வு செய்யலாம்; பலர் அதில் பரிச்சயம் பெற்று அதில் பயனர் கணக்கும் கொன்டுள்ளனர். மேலும்
தகவள்களுக்கு இல் உள்ள பகுதி ஐ பார்க்க, அதில் தொகுக்க பட்ட வளங்குதளம்
தேர்வு செய்யும் முன்பு பதிள்கான வேண்டிய கேள்விகள் பற்றி அறியலாம்.
ஒரு உரிமம் தேர்வு மற்றும் அதை விண்ணப்பித்தல்
இது மிகவும் சுருக்கமாக குறிப்பிடும் நோக்கத்தில், உரிம்ம தேர்வு பற்றிய மேம்போக்கான வழிகாட்டும் காட்டலுடன் உருவாக்கபட்ட பகுதி இது. என்ற பகுதியில் பல்வேறு பட்ட
உரிமங்களில் சட்ட உட்குறிப்புகளை பற்றி படித்து அறியலாம், மேலும் நீங்கள் தேர்வு செய்யும் உரிமம்
மற்றவர்கள் எப்படி உங்கள் மென்பொருளை அவர்களுடய மென்பொருளுடன் இனைத்து பயன் படுத்துவதை
கட்டுப்படுத்தும் என அறியலாம்.
இணைச் சொற்கள்: "கட்டற்ற மென்பொருள் உரிமம்", "FSF-ஒப்புதல் பெற்ற", "திறந்த
மூல உரிமம்", and "OSI-ஒப்புதல் பெற்ற"
"கட்டற்ற மென்பொருள் உரிமம்" மற்றும் "திறந்த மூல உரிமம்" என்ற இரண்டும் இணைச்
சொற்களே, மேலும் அவ்வாரே இந்த புத்தகம் முலுவதும் நான் பயன் படுத்தியுள்ளேன்.
அடிப்படையில், முதலில் குறிக்கபட்ட உரிமம் கட்டற்ற மென்பொருள் அறக்கட்டளையால்
கூரப்பட்ட நான்கு கட்டுப்பாடுகளையும் நிறைவு சேய்வது (
gnu.org/philosophy/free-sw.html என்ற இனைப்பை பார்க்க), அவ்வாரே இரண்டாவது
உரிமம் திறந்த மூல வரையறை படி எடுக்க பட்ட திரந்த மூல முன்முயற்சி (
opensource.org/osd). ஆயினும்,
நீங்கள் FSFஇன் கட்டற்ற மென்பொருள் வரையறை மற்றும் OSI திரந்த மூல மென்பொருள் வரையறை
ஆகியவற்றை படித்து பார்த்தால், இரண்டு வரையறைகளும் ஒரே சுதந்திரத்தை சித்திரிக்கின்றன என்பது
புரியும் —
இன்
இல் கூருவதைபோல் அதில் ஆச்சரியமில்லை.
தவிர்க்க முடியாமல், மேலும் வேண்டுமென்றே சிலவற்றையும் இரண்டு நிருவனங்களும் ஒரேமாதிரியான
உரிமங்களுக்கு ஒப்புதல் அளித்து விட்டன.அவற்றில் சிரிய வேருபாடிகள் இருந்தாலும்
நமது பயன் பாட்டிற்கு — அல்லது உண்மையில் அனேக நடைமுறை
காரணங்களுக்காக அவசியம் அற்றது. மற்றும் சில வேலைகளில், அவற்றில் ஏதேனும் ஒரு நிருவனம்
அதிக அளவு பயன்பாட்டில் இல்லாத உரிமத்தை ஒப்புதல் அளிக் தவரி இருக்கும். வெளிப்படையாக
கூரினால் ஆரம்ப காலத்தில் ஏதேனும் ஒரு நிருவன உரிமங்களில் ஒன்றில், இரண்டு நிருவனங்களிளும் கூட,
ஒரு வகையான வரையறை விட பட்டு இருக்கலாம் (எனவேதான் நான் அப்படி சொன்னேன்). எப்போது
எல்லாம் நான் இதை பற்றி விவரம் அறி முயற்சி செய்தாலும், அந்த உரிமம் என்ன என்பதை விட அப்படி
பெயரிடப்பட்ட ஒரு உரிமம் உள்ளது அதை எவரும் பயன் படுத்த வில்லை என்று மடுடம் மாறுபட்ட பதில்கள்
கிடைகிறது. எனவே இன்று, நீங்கள் எந்த உரிமம் பயன் படுத்தினாலும், "OSI-ஒப்புதல் பெற்றது" மற்றும்
"FSF-ஒப்புதல் பெற்றது" என்ற இரண்டும் ஒன்றுக்கொன்று உட்குறிப்பு என கருதலாம்.
தேர்வு செய்ய பல கட்டற்ற மென்பொருள் உரிமங்கள் உள்ளன. அவற்றில் பல வற்றை இங்கு
கருத்தில் கொள்ள அவசியம் இல்லை, அவை பெரும்பாலும் ஒரு குருப்பிட்ட நிருவனம் அல்லது தனி நபர்
சார்ந்து தனித்துவத்துடன் உருவாக்க பட்டவை, மேலும் அவை உங்கள் திட்டங்களுக்கு பொருந்தாமல்
இருக்கலாம். அதிக பயன் பாட்டில் உள்ள சில வற்றை பற்றி மட்டும் காணலாம், பெரும்பாலும் அவைகளில்
ஒன்றையே நீங்கள் தேர்தெடுக்க விரும்புவீர்கள்.
"எதையும்" அனுமதிக்கும் உரிமம்
29 August 2013: If you're reading this note, then
you've encountered this subsection while it's undergoing substantial
revision; see producingoss.com/v2.html for details. TODO: is
MIT or BSD still really the best default, given the modern patent
landscape? Would Apache-2.0 be better — but then what
about the FSF's claim of GPL-incompatibility? Need to get some advice
here.
If you're comfortable with your project's code potentially being
used in proprietary programs, then use
an MIT/X-style license. It is the simplest of
several minimal licenses that do little more than assert nominal
copyright (without actually restricting copying) and specify that the
code comes with no warranty. See
for details.
ஜிபிஎல் உரிமம்
நீங்கள் உங்கள் குறியீடுகளை தனியுரிம மென்பொருள் எவையும் பயன்படுத்துவதை விரும்பவில்லை
என்றால், குனு பொது மக்கள் உரிமம், பதிப்பு 3 பயன் படுத்துங்கள் (
gnu.org/licenses/gpl.html
). கட்டற்ற மென்பொருள் உலகில் ஜிபிஎல் அதிகம் பயன் படுத்த படும் உரிமம். இதுவே ஒரு பெரும் நன்மை, காரணம் இதை பற்றி பரும்பான்மையான பங்களிப்பாலர்கள் நன்கு அறிவர் எனவே உங்கள்
உரிமம் பற்றி தெரிந்து கொள்ள அவர்கள் அதிக நேரம் செலவிட மாட்டார்கள். மேலும் விவரங்களுக்கு
என்ற பகுதியை
-இல் பார்க்க.
ஒரு வேளை உங்கள் திட்டத்தில் தொடர்பு இணைய வழி முதன்மையாக இருந்தால்—அதாவது
உங்கள் திட்டம் இருமை கூறுகளாக இல்லாமல், இணைய வழங்கியில் தொகுத்து வலங்கப்படிருந்தால்—
பின்னர் GNU Affero GPL பயன் படுத்த பாருங்கள். ஏஜிபியல் இணையத்தில்
வினியோகம் செய்ய சிரப்பான பகுதி சேர்கப்பட்ட சதாரன ஜிபியல் உரிமம்தான். மேலும் விவரங்களுக்கு
என்ற பகுதியை
-இல் பார்க்க.
உங்கள் மென்பொருளுக்கு ஒரு உரிமம் அளிக்கும் முறை
ஒரு உரிமத்தை தேர்வு செய்த பின்னர், அதை நீங்கள் உங்கள் மேன்பொருளுக்கு அளிக்க வேண்டும்.
அதில் முதல் காரியம் அந்த உரிமத்தை திட்ட முதல் பக்கத்தில் தெளிவாக பதிவிட வேண்டும். அதில்
உரிமத்தில் முலுமையான கட்டுப்பாடுள் அனைத்தையும் அந்த பக்கத்தில் தர வேண்டிய அவசியம் இல்லை,
மாறாக அதை நீங்கள் வேரு பக்கத்தில் தந்து அதன் இணைப்பை இங்கு தரலாம். அது காண்பவருக்கு நீங்கள் எந்த உரிமத்தை பயன் படுத்த விரும்புகின்றீர்கள் என்பது தெளிவு படுத்து கின்றது—ஆனால் அது சட்டப்படி போதுமானது இல்லை. அடுத்ததாக மென்பொருளும் அந்த உரிமத்தை பயன்படுத்திருக்க வேண்டும்.
உரிமம் பயன்படுத்த நிலையான நடைமுறை COPYING (அல்லது
LICENSE) என்ற பெயரில் ஒரு கோப்பை உருவாக்கி அதில் உரிமம் பற்றிய முலு
தகவளையும் பதிவிட்டு குரியீட்டு கோப்பு தொகுப்புகளுடன் இணைக்க வேண்டும், மேலும் அதன் சுருக்க
கருத்துரையை அனைத்து குறியீட்டு கோப்புகளுடைய ஆரம்பத்தில் அந்த உரிமத்தில் தேதி, அதனை
உரிமையாலர் மற்றும் எங்கு முலு தகவளும் கொடுக்க பட்டுள்ளது என்ற விவரத்தையும் இணைக்க
வேண்டும்.
அதில் பல தரப்பட்ட மாற்று வடிவங்கள் உள்ளன, எனவே இங்கு ஒரே ஒரு உதாரணத்தினை
கான்போம். குனு ஜிபியல் கிளே குரிப்பிட்ட வாரு அனைத்து குறியீட்ட கோப்புகளின் துவக்கத்திலும் இணைக்க கூகிறது:
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>
உரிமத்தின் பிரதியை போதுவாக கொடுக்கும் COPYING அல்லது
LICENSE என்ற கோப்பில் உள்ளது என்பதை இது வெளிப்படையாக
சொல்லவில்லை. (நீங்கள் அந்த குரிப்பை வெளிப்படையாக கூரும்படி மாற்றி தரலாம், இருப்பினும் அது
அவசியம் அற்றது.)
பொதுவாக உங்கள் உரிம குறிப்புகள் அதன் தேதியுடன் உரிம விவரத்தை ஒரே மாதிரியா கொடுக்கும்
வரை, அது முற்றிலும் மேலே கூரப்பட்டதை போன்று இருக்க வேண்டியாது இல்லை.
உரிமம் காரணமாக அந்த கோப்பை மாற்றிய தேதியினை அதில் தர வேண்டும்.
வேறுவிதமாக கூறினால், 2008, 2009 மற்றும் 2013-இல் மாற்றப்பட்ட கோப்பில், நீங்கங்
"2008-2013"என்றில்லாமல் — "2008, 2009, 2013"
என்று குரிப்பிடுவீர்கள், காரணம் மற்ற இடைப்பட்ட காலங்களில் அது மாற்றப்பட வில்லை.
அந்த உரிமத்தின் பெயர் மற்றும் அதன் முலுவிவரமும் அடங்கிய கோப்பு எங்குள்ளது
என்பதையும் தெளிவாக குறிப்பிடுங்கள். உங்களால் இயன்றால், ஒரு சட்ட வள்ளுனரின் ஆலோசனை
பெருவது சிரந்தது.
தொனி சேர்ப்பது
இதுவரை நீங்கள் திட்ட ஆரம்பத்தில் ஒரு முறை செய்ய வேண்டி சேயல்களை பார்த்தோம்: உரிமம்
தேர்வு செய்தல், திட்ட துவக்க இணைய தளத்தை தயார் செய்வது போன்றவற்றை. ஆனால் திட்டத்தின்
முக்கிய காரியங்கள் அனைத்தும் தொடர் மாற்றத்திர்கு உரியவை. மின் அஞ்சல் பட்டியலை தேர்வு செய்வது
எளிது; அதில் நடக்கும் விவாதங்கள் ஆக்கபூர்வமாகவும் தீமை அற்றதாகவும் இருக்கும் படி வழிநடத்துவது
முற்றிலும் மாறுபட்ட காரியம். உதாரணமாக, ஏற்க்கனவே சில காலமாக நடந்து கொண்டுள்ள திட்டத்தை
கட்டற்ற திட்டமாக மாற்றும் பொலுது அதன் வளர்ச்சி செயல்முறைகள் மாறும் அதனைல் அதில்
பனியாற்றியவர்களை அதற்க்காக தயார் படுத்த நேரும்.
முதல் நடவடிக்கைகள் கடினமானவை, காரணம் முன்னுதாரனங்கள் மற்றும் எதிர் பார்புகள் இன்னும்
அமைக்க பட வில்லை. திட்டத்தின் நிலைப்புதன்மை அதன் வரையருக்கபட்ட கொள்கைகளில் இல்லாமல்,
காலப்போக்கில் உருவாகும் குறிப்பிட்டு காட்ட முடியாத பகிர்ந்து கொன்ட கூட்டு ஞானத்தில் கிடைக்கின்றது.
எழுதப்பட்ட கொள்கைகளும் உள்ளன, அவை உண்மையில் திட்டத்தை நிர்வகிக்கும் உணர்ந்தறிய முடியாத
தொடர்ந்து வளர்ந்து வரும் வழிகாட்டும் ஒப்பந்தங்கள்தான். எழுதப்பட்ட வரையறைகள் திட்டத்தின்
பன்பாட்டை தோராயமாக கூட தெறிவிப்பது இல்லை.
அப்படி செயல் பட சில காரணங்களும் உள்ளன. குவிக்கப்படும் சமூக வரையறைகளால் வளர்சி
மற்றும் அதிக கொள்முதல் மாற்றங்கள் எதுவும் நினைப்பதை போன்று சேதம் அடைவது இல்லை. மாற்றங்கள்
அதீத வேகத்தில் நடக்காத வரையில், புதியவர்கள் வந்து சேரவும் கற்றறியவும்
போதுமான கல அவகசம் இருக்கும், மேலும் அவர்கள் இணைந்து அந்தனை வலுப்படுத்துவார்கள். எப்படி
மலையர் பாடல்கள் பல நூற்றான்டுகள் தொடர்ந்து வருகின்றன அதை நினைத்து பாருங்கள். இப்போது
உள்ள குழந்தைகள் எவரும் நூறு வருடங்களுக்கு முன்பு இல்லை என்றாலும் ஏரத்தால அவர்கள் பாடிவாரே
இன்றும் பாடி வருகிரார்கள். சிறு குழந்தைகள் பெரியவர்கள் பாடியதை கேட்டார்கள், மேலும் அவர்கள்
வளந்து பெரியவர் ஆனபின்பு தன்னை விட சிறியவருக்கு பாடி காட்டுவர். அவர்கள் அதை பரவலாக்க
முடிவு செய்து பாடவில்லை என்றாலும் அவர்கள் வழக்கமாக மீண்டும் மீண்டும் பாடி அதனை பரப்பினார்கள்.
கட்டற்ற மென்பொருள்களின் கால அளவுகள் நூற்றாண்டுகளில் கணக்கிட படுவது இல்லை (நம்மால் அதன்
வாழ்நாளை செல்லவும் முடியாது), ஆயினும் பரப்புதல் தேவை கிட்டதட்ட அதேபோல் உள்ளன. ஆயினும்
பரிமாற்ற விகிதம் வேகமாக உள்ளதால், அதை தீவிரமாகவும் திட்டவட்டமாகவும் பரப்பும் முயற்சி மூலம்
ஈடுகட்ட வேண்டும்.
இந்த முயற்சி பொதுவாக மக்கள் உதவியை எதிர்பார்த்து வருவார்கள் மேலும் அதில் சமூக
நெறிகளுக்கான எதிர்பார்ப்பு இருக்கும் என்பதை அடிப்படையாக கொண்டது. அப்படிதான் மனித சமூகம்
உருவாகி உள்ளது. எந்த ஒரு குழுவிலும் ஒன்றுபட்ட பொதுவான முயற்சியால் இனைத்தவர்கள் உள்ளுணர்வு
எதிர்பார்கும் பண்புகள் ஒருங்கினைந்து போவதன் மூலம் குழுவின் அங்கத்தினர் ஆவார்கள். ஆரம்பதில்
முன்னோடிகளை அமைப்பது "குழுவின்" பண்பாட்டை அந்த திட்டத்திர்கு பயன் உள்ளவாரு செய்வதுதான்;
ஒருமுரை நிறுவியபின், அதில் தானாக பெருமளவிற்கு சுய நீட்டிப்பு இருக்கும்.
சிரந்த முன்னோடிகளை அமைப்பதர்கு பின் வருவன சில குறிப்பிட்ட உதாரணங்களை பின்பற்றலாம்.
அவை முலுமையான பட்டியல் இல்லை, ஆரம்பத்தில் கூட்டு மனப்பான்மையை அமைப்பதல் அது எப்படி
வியக்கத்தகு வகையில் ஒரு திட்டதிர்கு உதவியாக இருக்கும் என்பதன் உதாரணங்கள் மட்டுமே. உன்மையில்,
அனைத்து உருவாக்குபவர்களும் தாங்களாகவே பணியாற்றுபவர்கள், ஆனால் நீங்கள் அவர்கள் அனைவரும்
ஒரே அரையில் பணியாற்றுவது போன்று மனநிலை அமைய பல வற்றை செய்யலாம்.
அப்படி அவர்கள் அதிகம் என்னும் பொழுது, அதிக நேரம் ஈடுபாட்டுடன் செயல் பட முடியும். அதிகம் ஈடுபட்டு
அதிகமாக புரிந்து கொன்ட ஸப்வெர்ஸன்
(subversion.apache.org)
திட்டதில் வருவதால் நான் இந்த உதாரத்திணை தேர்வு செய்துள்ளேன். ஆயினும் அவை ஸப்வெர்ஸன்
திட்டதிற்கு மட்டும் பொருந்துபவை அல்ல; மேலும் பல்வேரு கட்டற்ற மென்பொருள் திட்டங்களில் இத்தகைய
சூழல் உருவாவதால் இதனை செயல்களை துவங்க கிடைத்த சிறந்த வாய்ப்பாக கருதலாம்.
தனிமை படுத்த பட்ட விவாதங்களை தவிர்க்கவும்
திட்டத்தை திறந்த மூலமாக மாற்றிய பின்பும், நீங்கள் மற்ற நிறுவுனர்களும் சில கடினமான
தருனங்களை தனியாக விவாதித்து தீர்வுகான முயற்சி செய்யலாம். இது திட்டத்தின் ஆரம்ப காலத்தில்
தகுதி படைத்த மிக குறைவான தன்னார்வளர்களும் அதிக முக்கியமான பல முடிவுகள் எடுக்க வேண்டி
உள்ளதால் இவ்வாறு நடக்கலாம். கையாளக்கூடிய பொது விவாதங்களில் உள்ள அனைத்துவித குறைபாடுகளும்
உங்கள் முன் தோன்றும்: மின் அஞ்சல் விவாதங்களில் உள்ள தாமதம், ஒருமித்த என்னம் தோன்ற தரப்பட
வேண்டிய நேரம், எதையும் தெளிவாக தெரிந்து கொள்ளாமல் எல்லாம் புரிந்தது போன்று செயல் படும் சில
அப்பாவியான தன்னார்வலர்களால் தோன்றும் குழப்பங்கள் (எல்லா திட்டங்களிளும் இது உள்ளது; சில
நேர்ம அவர்கள் வருங்கால சிறந்த பங்களிப்பாலர்களாக இருப்பார்கள், சில சமயம் அவர்கள் அப்படியே
அப்பாவியாக இருந்து விடுவார்கள்), Y என்ற பெரிய சிக்கலின் X என்ற சிறிய பகுதிக்கு மட்டும் ஏன்
இத்தகைய முக்கியத்துவம் தர்ப்பட வேண்டும் என்று புரிந்து கொள்ளாதவர்கள் மற்றும் பல. அப்படி செய்யாமல்,
மூடிய அரைக்குள் தனிப்பட்ட முறையில் விவாதம் செய்து அதை faits
accomplis (நிர்பந்தத்தால் நிரைவேற்ற பட்டது) அல்லது ஒருங்கினைந்த மற்றும் முக்கிய
வாக்குகளால் பரிந்துரை செய்யப்பட்டது என்று குறிப்பிட்டு வெளியிட தோன்றும் சலனம்.
அதை செய்ய வேண்டாம்.
பொது விவாதங்கள் மெதுவாக மற்றும் சிக்கலாக இருப்பினும், அதுதான் நீண்ட நாள் வளர்சிக்கு
உகந்தது. தனிப்பட்ட முடிவுகளை எடுப்பது பங்களிப்பாலர்களை தடுக்கும் காரணிகளை பரப்புவதை போன்றது. எந்த ஒரு தீவிர பங்களிப்பாளரும், முக்கிய முடிவுகள் எடுக்கும் ரகசிய குழு உள்ள திட்டத்தில் நீடித்து இருக்க மாட்டார்கள். மேலும், குறுகிய கால தோழில்நுட்ப கேள்வி எதுவாக இருந்தாலும் அதை பொது விவாதம் செய்யும் போது நீன்ட கால நன்மை பயக்கும் பக்க விளைவுகள் உண்டு:
அது புதிய வளப்படுத்துபவர்களுக்கு பயிர்சி தர உதவும். உங்களுக்கு பொதுவாக எவ்வளவு
பேர் உங்கள் திட்டத்தை கவணித்து கொண்டு உள்ளார்கள் என்று தெரியாது; பலர் பங்கேற்க
வில்லை என்றாலும், அமைதியா இருந்து பார்துகொண்டு இருப்பார்கள், பலவற்றிலிருந்தும் மென்பொருள் பற்றியா தகவள்களை சேகரித்து கொண்டு இருப்பார்கள்.
அந்த விவாதங்கள் உங்களுக்கு அந்த மென்பொருள் பற்றி
போதுமான தெளிவு இல்லாதவர்களின் தொழில் நுட்ப கேள்விகளுக்கு எப்படி பதில் கூர வேண்டும்
என்ற பயிற்சியாக இருக்கும். அந்த திறமை பயிற்சியால் வருவது, மேலும் அதை உங்கள்
மென்பொருளை பற்றி நன்கு அரிந்தவர்கள் உடன் விவாதித்து பெர முடியாது.
அந்த விவாதங்கள் மற்றும் அதன் முடிவுகள் என்றும் பொது காப்பகங்களில் இருக்கும்,
அதனால் எதிர்கால விவாதங்கள் அனைத்திலும் அதே வழிமுரைகள் பின்பற்றுவதை தடுக்கும்.
மேலும் விவரங்களுக்கு
என்ற பகுதியை இல் பார்க்க.
இருதியாக, நீங்கள் சற்றும் எதிர் பாராத தீர்வு ஒன்றை, அந்த பட்டயலில் உள்ள எவரேனுன் கூரி
உறிய பங்களிப்பை அந்த விவாதத்திர்கு தருவர். அதை அவ்வளவு உறுதியாகவும் சொல்ல முடியாது; அது முற்றிலும் அந்த குறியீடு எத்தகைய கடினமானது மற்றும் எத்தகைய சிரப்பு திரமை தேவைபடுகின்றது என்பதை
பொருத்தது. ஆயினும் தனிப்பட்ட விவாதங்களின் இடைநிகழ்வு தடயங்கள் அனுமதிக்க பட்டால், நீங்களு
உள்ளுனர்வில் நினைப்பதை விட விளைவுகள் அதிக மோசமாக இருக்கும். ஸப்வெர்சன் திட்டதில், நாங்கள்
(நிருவியவர்கள்) பல மாதங்களாக கடினமாக சிந்தித்து மிகவும் கடினமாக மற்றும் ஆழமானதாக கருதிய, ஒரு
பிரச்சனையை, புதிதாக அமைத்த அஞ்சல் பட்டியலில் உள்ள எவராலும் தீர்க முடியாது என்று என்னினோம்.
எனவே நாங்களாகவே தனிப்பட்ட அஞ்சல் பட்டுயலில் விவாதித்து கொண்டிருந்தோம், அதை ஒரு பார்வையாளர்
கவணிக்கும் வரை செய்து வந்தோம்கௌரவம் கொடுத்தல் பற்றி நாம் இன்னும் விவாதிக்க
வில்லை இருப்பினும், நான் என்றும் மற்றவருக்கு செல்லித்தருவதை நானும் கடைபிடிக்க வேண்டும் என்பதில்
உருதியானவன் என்பதால் சொல்கிறேன்: அந்த உற்றுநோக்குபவரின் பெயர் Brian Behlendorf, மேலும்
அவர் சிரப்பு காரணங்கள் எதுவும் இல்லாத பொழுது பொதுவான விவாதம் செய்வது மிகவும் அவசியம் என்பதை
உறுதியாக வற்புருத்தி வந்தார். அதை அவர் கண்டுனர்தவுடன் அதை பொதுவாக
விவாதிக்க வற்புருத்தினார். சற்று தயக்கதுடன் நாங்களும் அதை செய்தோம்—ஆனால் அதனால்
கிடைத்த உள்ளார்ந்த பதில்களை பார்த்த பொழுது முற்றிலும் வியப்பிள் ஆல்துவிட்டோம். பல சூழ்நிலைகளில்
மக்கள் கொடுத்த யோசனைகள் நாங்கள் முற்றிலும் எதிர் பார்திராத்து. அது அந்த பட்டயலில் சில
மிகவும் நுன்னறிவு கொண்டவர்கள் இருக்கிரார்கள் என்பதை சுட்டி காட்டியது;
அவர்கள் ஒரு சிரந்த தருனதிர்காக காத்திருந்தனர். தனிப்பட்ட விவாதங்களை விட பொது விவாதங்கள் சற்று
காலதாமதம் ஏற்படுத்த கூடியவைதான், இருப்பினும் அவை அதர்க்காக கொடுக்க படும் நேரத்தை காட்டிலும் சிரந்த பலன் தரும்.
"தனி மனிதரை விட குழுவாக செயல்படுவது அறிவார்ந்ததாக இருக்கும்" என்று உடனடியாக
பொதுமையாக்கல் செய்துவிடவும் முடியாது (நாம் அனைவரும் பல குழுக்களை சந்தித்து உள்ளோம்), ஆனால்
சில குருப்பிட்ட காரியங்களில் குழு திறமை மிக்கதாக உள்ளது. பொரிய அளவிலான தனிநபர் பரிசீலனை
அதில் ஒன்று; பல புதிய யோசனைகளை உருவாக்குவதும் அதில் ஒன்று. யோசனைகளின் தரம் அதை வர்கள்
புரிந்து கொண்டதன் தரத்தினை சார்ந்தது, ஆயினும், எப்படி பட்ட சிந்தனையாலர்கள் உள்ளனர் என்பதை நீங்கள் ஒரு குழப்பமான பிரச்சனை தந்து தூண்டிவிடுவதால் மட்டுமே அறிய முடியும்.
இயல்பாகவே, சில முக்கிய விவாதங்கள் தனிப்பட்ட முரையில் செய்யப்பட வேண்டும்; இந்த புத்தகம்
முலுவதும் அத்தகைய உதாரணங்களை காண்போம். ஆயினும் வழிநடத்தும் தத்துவம் என்றுமே:
தனிப்பட்ட விவாதம் செய்ய எந்த ஒரு காரணமும் இல்லை என்றால், அது கண்டிப்பாக பொது
விவாதமாக இருக்க வேண்டும்.
இதை நடக்க செய்ய சில நடவடிக்கை தேவை. அதற்கு உங்களில் அனைத்து பதிவுகளும் பொது
பட்டியலுக்கு செல்லும் படி செய்வது மட்டும் போதாது. மற்றவர்களில் தேவையற்ற தனிப்பட்ட விவாதங்களையும்
நீங்கள் பொதுவாக விவாதிக்கும் படி செய்ய வேண்டும். ஒரு வேலை ஒருவர் உங்களுடன் அவசியம் அற்ற
தனிப்பட்ட விவாதம் செய்ய துவங்கினால், அதை பொதுவிவாதமாக மாற்றுவது உங்கள் கடமை ஆகிரது. அந்த
விவாதத்தை முற்றிலும் பொதுவிவாதமாக மாற்றும் வரை அல்லது தனிமை முற்றிலும் தவிர்க முடியாது என்பதை உருதி செய்யும் வரை அதர்க்கு எத்தகைய பதிலும் தராதீர்கள். அப்படி நீங்கள் செய்ய துவங்கினால் மற்றவர்களும் எளிதில் பொதுவிவாத கலத்தை பின்பற்ற துவங்கி விடுவார்கள்.
முரட்டுதனங்களை முளையிலேயே கிள்ளி எறிந்துவிடுங்கள்
திட்டத்தின் துவக்கத்தில் இருந்தே, முரட்டு மற்றும் அவமதிக்கும் செயல்களுக்கு துளியும் இடம்
தரக்கூடாது. துளியும் அனுமதிக்க கூடாது என்றால் அவர்களில் பதிப்பு உரிமையை பறிப்பது மற்றும் அஞ்சல் பட்டியலில் இருத்து விளக்குவது போன்ற தொழில் நுட்ப கட்டுபாடுகளை தருவது என்று இல்லை.
(நடைமுறையில், அனைத்து விதமான முயற்சியும் பொய்த்த பின்னர் நீங்கள் இத்தகைய செயல்களில் ஈடு பட
நேரலாம்.) துளியும் இடம் தர வேண்டாம் என்றால் தவரான நடவடிக்கைகள் எதையும் கண்டு கொள்ளாமல்
இருக்க வேண்டாம் என்பதுதான். உதாரணமாக, எவராவது ஒரு தொழில் நுட்ப கருத்தை
ad hominemயுடனை இணைத்து மற்ற மேம்படுத்துபவரை
புன்படுத்தினால், அத்தகைய ad hominem கருத்தை பற்றி மட்டம் தொழில் நுட்ப கருத்தில் இருந்து விழக்கி நீங்கள் சுட்டி காட்ட வேண்டும்.
ஆக்க பூர்வமான விவாதங்கள் கூட சில சமையம் அழிவு பூர்வமாக மாறிவிடுவது என்பது
துரதிருஷ்டவசமானது, மேலும் அது தவிர்கமுடியாமல் அடிக்கடி நடப்பது. நேருக்கு நேராக செல்லாதவற்றை
கூட மின் அஞ்சலில் பலரும் தெருவிப்பர். விவாதத்தின் தலைப்பு அதனை ஊக்குவிக்கும் விதமாக இருக்கும்:
தொழில் நுட்ப கேள்விகளுக்கு என்றும் ஒரே ஒரு பதில்தான் உள்ளதாக பலரும் நினைக்கின்றனர், அப்படி அந்த
தீர்வுக்கு மாற்று கருத்து இருப்பின் அதற்கு கவனக்குறைவாகவும் முட்டால்தனமாகவும் பதில் கூருவது மட்டுமே
ஒரே வழியாகவும் அவர்கள் நினைக்கிறார்கள். ஒருவாரின் தொழில் நுட்ப பரிந்துரையை முட்டால் தனம் என்று
கூருவாது அவரை முட்டால் என்று சொல்லுவதர்கு சமமானது. நடமுரையில், எந்த இடத்தில் தொழில் நுட்ப
விவாதம் முடிந்து எப்பொழுது தனிநபர் எதிர்பு துவங்கியது என்று கணிப்பது கடினம், அதனால்தான் கடுமையான
தன்டனை அல்லது தடைகள் சரியான செயலாக இருக்காது. எனவே நீங்கள் அப்படி நடக்கும் பொழுது,
எவரும் தவரான செயல்களை வளர்க்காமல் தடுக்க, நட்பு ரீதியான விவாதத்தின் அவசியத்தை உணர்தும் ஒரு கட்டூரையை பதிவிடுங்கள். அத்தகைய "மென்மையான கொள்கை" மழலையர் பள்ளியில் நன்நடத்தை பாடம்
புகட்டுவது போல் தோற்றம் தரும்:
முதலில், (சாத்தியமுள்ள) தனிப்பட்டக் கருத்துகளை முடிந்தவரை குரைத்து
கொள்ள முயர்சி செய்ய வேண்டும்; உதாரணமாக, ஜெ என்பவரின் பாதுகாப்பு அடுக்கு வடிவமைப்பை
"கணிப்பொரி பாதுகாப்பு அடிப்படை அம்சங்கள் எதுவும் அற்ற அப்பாவியான மற்றும் அடிப்படை அறிவு இல்லாத வடிவமைப்பு." என்று கூருவது சரியாகவும் இருக்கலாம் அல்லது தவறாகவும் இருக்களாம்,
எதுவானாலும் அத்தகைய வார்த்தைகள் அவசியம் அற்றவை. ஜெ அவரின் பங்களிப்பை நல்ல
நம்பிக்கையுடன் சொல்லி இருக்க வேண்டும். அதில் தவறுகள் இருப்பின், சுட்டி காட்டுங்கள், மேலும்
நாம் அவற்றை திருத்துவோம் அல்லது வேரு ஒரு வடிவமைப்பை பொரலாம். எம் எந்த வகையிலும்
ஜெவை இழிவுபடுத்த சொல்லவில்லை என்று நான் நம்புகிரேன், இருப்பினும் அந்த சொற்றொடர்
தவிர்க்க பட வேண்டியது மேலும் இங்கு அனைத்து விவாதங்களையும் ஆக்க பூர்வமாக இருக்கும் படி
பார்து கொள்ள முயல வேண்டும்.
மீன்டும், முன்மொழிய பட்ட அந்த திட்டத்தை பார்த்தால். எனது நம்பிக்கை படி
எம் சரியாக சொல்ல நினைத்து...
அத்தகைய பதில் பகட்டானதாக் தோன்றினாலும், அவை பலன் தரக்கூடியவை. தவறான முறையில்
செல்ல பட்ட பதில்களை தொடர்ந்து கவணித்து சொன்னவரை சுட்டிகாட்டாமலும் வருத்தம் தெரிவிக்க வற்புருத்தாமலும் மாற்று கருத்தை சொல்லி வந்தால், அது அவர்களுக்கு ஆசுவாச படுத்த நேரம் தந்து அடுத்த முரை கவனத்துடன் பதில் சொல்ல வாய்பு தரலாம்—அவர்களும் அதை செய்வார்கள்.
இத்தகைய மாருபட்ட விவாதங்களை முக்கிய விவாதங்களாக மாராமல் பார்து கொள்வதுதான் அதை
வெற்றிபெர வைக்க சிரந்த இரகசியம். அது முற்றிலும் குரைந் முக்கியதுவத்துடன் முக்கிய விவாதத்தின் ஒரு
சிருபகுதியாக மட்டுமே இருக்க வேண்டும். இங்கு கவணிக்க வேண்டியது "நாம் இப்படிபட்ட செயல்களை
இங்கு செய்வது கிடையாது" என்று குறிப்பிட்டு அந்த முக்கிய விவாதத்தினை பற்றியும் சிறிது சொல்லி முடிப்பது
மற்றவர் அந்த விவாதத்தை பற்றி பதில் கூர ஏதுவாக இருக்கும். யாரேனும் நீங்கள் கூரியதை தவராக
நினைத்து ஏதேனும் கூரினால் அவர்களின் கருத்தை சற்று பொருட்படுத்தாமல் விடுங்கள். அவர்களுக்கு
பதில் கூராமல் விட்டு விடுங்கள் (ஒருவேலை பதில் அழிக்க அவசியம் அற்றதை வெருமனே வெருப்பை
கொட்டிவிடும் வார்த்தைகளில் சொல்லி இருந்தால்), அல்லது அதிகப்படியான பதில் வினை செய்ததாக
கருதினால் மன்னிப்பு கேட்டுவிட்டு மீன்டும் முக்கிய விவாதத்தினை பற்றி ஏதேனும் குறிப்பிடங்கள். எக்காரனம்
கொண்டும் ஒரு குறிப்பிட்ட நபரின் செயலை தனியாகவோ அல்லது பொது விவாதத்திலோ குறைகூர
வேண்டாம். அவர்களாக வருத்தம் தெருவிக்க விரும்பினால் நல்லது, ஆயினும் அதனை வர்புருத்தி செய்ய
சொல்வது மனக்கசப்பை உருவாக்கும்.
இருதியான இலச்சியம் "குழுவின்" நல்ல நடத்தைகளை அன் இயல்பான பண்பாக வளர்ப்பது மட்டுமே.
அது திட்டதிர்கு உதவியாக இருக்கும், தேவையற்ற சன்டைகள் இருப்பில் (அவர்கள் அந்த திட்டதை விரும்பி
உதவ நினைத்தாலும்) மேன்பாட்டலர்கள் விலகி சென்றுவிடுவார்ள். அவர்கள் விலகியது கூட உங்களால் கவணிக்க முடியாது; சிலர் திட்ட விவாதங்களில் பங்கு பெருவாது கடினமாக உள்ளது என்று
அஞ்சல் பட்டியலில் விவாதங்களுக்கு பதில் தராமல் பதுங்கி விடலாம். விவாத மேடையை நட்புடன் நடத்தி
வருவது திட்டதினை நீன்ட நாள் வாழ வைக்கும், மேலும் அது சிறிதாக இருக்கும் பொழுதே அப்படி செய்வது
எளிது. அது திட்டதின் பண்பாடாக மாறிய பின்னர், நீங்கள் மட்டுமே அதனை வளியுத்துபவராக இருக்க
மாட்டீர்கள். அது அனைவராலும் பதுகாக்க படும்.
கவனத்தைக் கவர்கிற வண்னம் குறியீட்டு விமர்சனம் செய்ய பலகுங்கள்
வளர்ச்சி மிக்க உருவாக்குபவர்கள் குழுவை நிருவ முக்கியமான விதி ஒருவரின் குறியீட்டை மற்றவர்
கவணிக்கும் படி செய்வதே ஆகும் — பலவகையில், ஒருவர் செய்த குறியீட்டை அவர்
மாற்றம் செய்த உடனே மற்றவர் காண செய்வது சிரந்தது.
பதிவீட்டு விமர்சனம் (சில நேரங்களில் குறியீட்டு
விமர்சனம்) என்பது பதிவு செய்ய பட்ட உடனே, பிழைகள் கண்டரிய மற்றும் செப்பனிட,
செய்யப்படுவது ஆகும்.
புதிதாக பதியப்படும் மற்றங்களை சிலகாலமாக உள்ள குறியீடுகளை விட முக்கியதுவம் தந்து விமர்சிப்பது
சில காரணங்கலுக்காக நன்மை தரும். முதலில், அது குழுவாக செய்வது: ஒருவர் உங்கள் மற்றத்தை பற்றி
விமர்சிப்பது அவர் உங்கள் அன்மை கால மாற்றத்தை பற்றி விவாதிப்பதாக இருக்கும் பொழுது அதில் ஆர்வம் அதிகம் காட்ட முடியும். ஆறு மாதங்கள் கலிந்த பின்னர் அவர் விமர்சித்தால் உங்களால் அந்த மாற்றதை
நினைவு கூர இயலாது மட்டும் இன்றி அதில் கவணம் செலுத்தவும் போதிய விருப்பமும் இருக்காது. இரண்டாவதாக, எந்த மாற்றம் செய்யப்பட்டது என்பதை காண முயற்சி செய்வதே குறியீட்டு களத்தை ஆய்வு
செய்ய கிடைக்கும் சிரந்த வாய்பு — குறியீட்டு விமர்சனம் செய்ய முயர்சி செய்யவதால்
அது பொதுவாக ஒருவரை அதை சார்ந்த குறியீடுகளை, அது மேற் கொள்ளும் தொடர்புகளை, அது மற்ற
தொகுப்புகளுடன் கொன்டுள்ள சார்பு மற்றும் பலவற்றை பற்றி அரிந்து கொள்ள வாய்ப்பை உருவாகி தரும்.
இவை அனைத்தும் ஆரம்பம் துவங்கி இருதிவரை செய்யப்படும் முலு குறியீட்டு
விமர்சனத்தை, உதாரணமாக பாதுகாப்பு தணிக்கை பொன்றவற்றை தவிர்க்க அல்ல. அத்தகைய விமர்சனங்கள்
அவசியம் என்றாலும், இது அதிகமாக மேம்பாட்ட நடவடிக்கையில் நல்ல பண்பாடாக மட்டுமே உள்ளது, மேலும்
இது கட்டற்ற மென்பொருளை மாற்றம் செய்ய செய்ய விமரசன் செய்வதை போன்று குறிப்பிட்டு இருக்காது.
பதிவு விமர்சனம் அதனால் பல வகையில் உதவுகின்றது. இது கட்டற்ற மென்பொருள் தரத்தை
நிர்வகிக்க உதவுவதுடன் சமமானவர்களில் பரிசீலனையை பரைசாற்றும் நல்ல உதாரணம் ஆகும். பிழைகள்
அனைத்தும் பதிவின் போதே கலைய்படுவதால் அவை வெளியீட்டிர்கு பின்னர் கண்டு பிடிக்க படுவது தவிர்க்க
படுகின்றது; அதனால் வெளியீட்டிர்கு பின்னர் மிக குறைந்த பிழைகள் மட்டுமே இனம்கானப்படு கின்றன.
இதில் மறைமுகமான பலனும் உள்ளது: தனக்கு விருப்பம் உள்ளதில் மட்டுமே எவரும் கவணம் செலுத்துவர் என்பதால் இது பங்களிப்பர்களின் விருப்பத்தை அரிய பயன்படுகிறது. மற்றவர் அந்த மாற்றங்களை விமர்சனம்
செய்வார்கள் என்பதை உணர்வதால் அவர்கள் சிரப்பாக செய்ய முயற்சி செய்வார்கள்.
விமர்சனம் முற்றிலும் பொதுவாக நடக்க வேண்டும். நாங்கள் ஒருவருக்கு ஒருவர் அருகாமையில் ஒரே
அரையில் இருப்பினும், எங்களில் ஒருவர் குரியீட்டு பதிவினை செய்த உடன் மற்றவர் அதை பற்றிய
விமர்சனத்தை தனியாக விவாதிக்காமல் பொது மன்றத்தில் விதிப்பதிக்கும் படி பார்து கொள்வோம். அந்த
விமர்சனத்தால் அனைவரும் பயன் பெருவர். அதில் சிலர் குறைகளையும் கண்டரியலாம்; அப்படி இல்லை
என்றாலும், விமர்சனங்கள் பாத்திரங்களை கலுவுதல் அல்லது வாசலை சுத்தம் செய்தல் போன்று அவசியமான
செயல் என்பதை அவர்களுக்கு நினைவு படுத்தும்.
பதிவு பின் பதிவாக விமர்சனம் செய்ய தொழில் நுட்ப வசதியும் அவசியம். குறிப்பாக பதிவு
சுருக்கத்தை விநியோகிக்கும் மின் அஞ்சல் அமைப்பது. பதிவு அஞ்சல் என்பது ஒவ்வொரு முரையும் ஒருவர்
பதிவு செய்யும் போதும் அந்த பதிவை பற்றிய செய்தியுடன் அந்த மாற்றத்தையும் (அந்த மாற்றங்கள்
மிகப்பொரிதாக இருக்காவிடில் மேலும் அறிய என்ற பகுதியை
இல் பார்க்கவும்). விமர்சனம் அந்த மின் அஞ்சலில் சிரு பகுதியை
எடுத்து, அல்லது Gerrit மற்றும் GitHub போன்றவற்றின் "மிகுதி கோரிக்கை" இடைமுத்தை கொண்டும்
கூட செய்யப்படலாம். மேலும் விவரங்களுக்கு
என்ற பகுதியை
யில் பார்க.
மாதிரி நிகழ்வு
ஸப்வெர்சன் திட்டத்தின் ஆரம்பத்தில் நாங்கள் குரியீட்டு விமர்சனத்தை தொடர் நிகழ்வாக செய்ய
வில்லை. அங்களுக்கு விருப்பமான பகுதியில் செய்யப்படும் மாற்றத்தை ஒருவர் விமர்சனம் செய்தாலும் அது
உறுதியாக செய்யப்படும் என்பதற்கு எந்த நம்பிக்கையும் இல்லை. எளிதில் இணம் கண்டுகொள்ளக்கூடிய
பிழைகளுட்ம் வினியோகம் செய்யப்பட்டது. க்ரைக் ஸ்டைன் (Greg Stein) என்ற குறியீட்டு விமர்சனத்தின்
பலனை உனர்ந்த மேம்பாட்டாலர் ஒவ்வொரு பதிவிலும் உள்ள ஒவ்வொரு வரியையும்
படித்து விமர்சித்து ஒரு உதாரணமாக இருக்க விரும்பினார். எனவே ஒவ்வொரு குறியீட்டு பதிவும் அவரிடம்
இருந்து அதன் விளைவுகள், அதில் இருக்கும் பிழைகளுக்கான காரணிகள், மேலும் பல முரை சிரப்பான பதிவை பாராட்டியும் கொண்ட ஒரு மின் அஞ்சல் விமர்சனத்துடன் தொடரப்பட்டது. உடனுக்கு உடன் அவர்
பிழைகள் மற்றும் செலுமை அற்ற குறியீட்டு பயன்பாடுகள் ஆகியவற்றை கண்டரிந்தார், அப்படி செய்ய வில்லை
என்றால் அவை கண்டர்யப்படாமல் நலுவி இருக்கும். அவர் மட்டுமே குறியீட்டு விமர்சன் செய்வதால் அது
அவருக்கு நேர விரயம் செய்தாலூம் அதன் முக்கியதுவத்தை வாய்ப்பு கிடைக்கும் பொழுதெல்லாம் சுட்டி
காட்டவும் செய்தார். மிக விரைவில் என்னையும் சேர்த்து மற்றவர்களும் ஒவ்வொரு பதிவையும் ஆய்வு செய்யது
விமர்சனம் செய்ய துவங்கினர்.
எங்களை ஊக்குவித்தது என்ன? க்ரைக் அவர்கள் எங்களை தொடர்ந்து வெட்கப்படும் வகையில்
செய்த்துதான். ஆயினும் அவர் நிரூபித்தது, புதிய குறியீட்டை பதிவு செய்து பங்களிப்பதை போன்று மற்றவர்
பதிவுகளை ஆவு செய்து விமர்சனம் செய்யவதும் மிகவும் பயன் தரக்கூடியது, மேலும் அது நாம் செலவிடும்
நேரத்தை பயனுள்ளதாக்கும் என்பது தான். அதை அவர் செயல் படுத்தி காட்டிய உடன் அது எதிர்பார்க படும்
செயல் ஆகி விட்டது, மேலும் எந்த ஒரு விமர்சனமும் கிடைக்காவிடில் அந்த பதிவை செய்தவருக்கு அச்சம்
ஊட்டி, யாரேனுன் அந்த பதிவை ஆய்வு செய்ய முடிந்ததா என்று வெளிப்படையாக கேட்டகவும் தூன்டியது.
பின்னர், க்ரைக் அவர்களுக்கு வேரு ஒரு திட்டத்தில் பனியாற்ற தேவை இருந்ததால், ஸப்வெர்சன் திட்டத்தை
தொடர்ந்து ஆய்ந்து விமர்சனம் செய்ய முடியாம்ல போனது. ஆயினும் அதர்க்குல், அந்த பன்பாடு
மற்றவர்களுக்கு வந்து சில காலமாக தொடர்ந்து செய்து வருகின்றோம்.
முதல் பதிவில் இருந்தே ஆய்வு செய்து வாருங்கள். பாதுகாப்பு குறைபாடுகள், சேமிப்பு கசிவு,
குறைவான விளக்க குறிப்புகள் அல்லது API ஆவனங்கள், தவரான நிபந்தனை கூற்றுகள் கொண்ட, கண்ணிகள், வரைமுறை தவரிய சார்பு அழைப்புகள் மற்றும் இதை போல் சூழல் பற்றிய விவரம் குறைவாக
தேவைப்படும் அனைத்து பிழைகளும் பதிவு வேறுபாட்டில் இருந்தே கண்டுபிடிக்க கூடியவை. ஆயினும்,
தொடர்ந்து திறனாய்வு செய்து வந்தால், மீன்டும் மீன்டும் பயன் படும் குறியீட்டு தொகுப்புகளை பிரித்தெடுத்து
தனியாக தொகுத்து சார்புகளாக பயன் படுத்த தவரிய இடங்களை கூட கண்டுபிடித்து விடலாம், காரணம்
முந்தய குறியீட்டு வேறுபாட்டில் செய்த குறியீட்டு திறனாய்வின் நினைவு இவற்றை எளிதில் அடையாலம்
காண உதவும்.
நீங்கள் திறனாய்வில் விமர்சனம் செய்ய எதுவும் இல்லை என்றோ அல்லது அந்த மாற்றம் பற்றிய போதுமான அறிவு இல்லை என்றோ கவளைப்பட வேண்டாம். கிட்டதட்ட அனைத்து பதிவை பற்றியும் சொல்ல
ஏதாவது ஒன்று இருக்கும்; நீங்கள் கேள்வி கேட்க எதுவும் இல்லை என்றாலும், பாராட்ட எதாவது இருக்கலாம்.
அதில் முக்கியமானது என்ன வென்றால் பதிவு செய்தவருக்கு அதனை மற்றவர்கள் கவணித்து புரிந்து
கெண்டார்கள் என்ற நம்பிக்கை வரவேண்டும். பதிவு செய்வதர்க்கு முன்பு பறிசோதனை மற்றும் சுய திறனாய்வு
செய்ய வெண்டும் என்பதன் அவசியத்தை குறைப்பது திறனாய்வின் நோக்கம் அல்ல; எவரும் திறனாய்வை மட்டும்
நம்பி செயல் பட கூடாது.
முதல் நாளில் இருந்தே திரந்த மூலமாக கொடுங்கள்
முதல் நாளில் இருந்தே உங்கள் திட்டத்தை திரந்த மூலமாக துவங்குங்கள். எத்துனை காலம் தனி
உறிமை பெற்ற திட்டமாக இரந்ததோ அதற்க்கு சரிவிகிதத்தில் திரந்த மூலமாக மாற்றவதும் கடினமாக
இருக்கும்.இந்த பகுதியில் உள்ள அனைத்து தகவள்களையும்
blog.civiccommons.org/2011/01/be-open-from-day-one என்ற வலைப்பதிவில் எழுத துவங்கி பின்பு இங்கு இனைப்பதர்காக சில மாற்றங்கள் செய்யப்படது.
துவக்கத்தில் இருந்தே கட்டற்ற மென்பொருளாக வழங்க வேண்டும் என்பது உங்கள்
மேம்பாட்டாலர்களும் சமூக மேலான்மையின் அதிகப்படியான பொருப்பை ஏற்றக வேண்டும் என்று இல்லை.
"கட்டற்ற மென்பொருள்" என்றால் "அரிமுகம் அற்றவர்கள் கேள்விகள் கேட்டு கவனத்தை திருப்புவார்கள்"
என்னும் என்னம் பொதுவாக உள்ளது — தமு முற்றிலும் அவசியம் என்றால் நீங்களே
அதற்க்கான தருநத்தில் செய்யலாம். அது முற்றிலும் உங்கள் கட்டுபாட்டில் உள்ளது. பகிரங்கமாக புலப்படும்
மன்றங்கள் கொன்டு துவக்கதில் இருந்தே உங்கள் திட்டதை செயல் படுத்துவது பல நன்மைகளையும் கொண்டுள்ளது. மாறாக, எவ்வலவு காலங்கள் உங்கள் திட்டம் தனியுரிமை திட்டமாக உள்ளதோ, அந்த
அளவு அந்த திட்டத்தை கட்டற்ற மூலமாக மாற்றுவதும் சிரமம்.
அதற்கு ஒரு அடிப்படை காரணம் இருக்கிறது என்று நான் நினைக்கிறேன்:
அனைத்து கட்டதிலும், மேம்பாட்டாளர்கள் ஒரு தேர்வு செய்ய வேண்டி உள்ளது: அனுமானிக்க பட்ட
வருங்காள கட்டற்ற மென்பொருள் ஆக்கும் திட்டதிர்கு ஏதுவாக அந்த செயலை செய்ய வேண்டுமா அல்லது
கட்டற்ற மென்பொருளாக்கதிர்கு எதிராக இருக்க வேண்டுமா என்ற தேர்வு. மேலும் ஒவ்வொரு முறை அவர்கள்
அந்த இரண்டாவது வழியை தேர்வு செய்யும் போதும் அது கட்டற்ற மென்பொருள் ஆக்கும் திட்டதை கடின மாக்குகின்றது.
முக்கிய விஷயம் என்னவென்றால், அவர்கள் அப்படி இரண்டாவதை தேர்வு செய்வதை தவிர்க்க
முடியாது — மேன்பாட்டு நடவடிக்கையின் அனைத்து அழுத்தங்களும் அதை செய்ய
வைத்துவிடும். சோதிப்போர்கள் கண்டரியும் பிழைகளை திருத்துவது, அல்லது வாடிக்கையாளர் புதிதாக
விவரக்குறிப்பில் இனைத்த அம்சத்தை உருவாக்குவது போன்ற நிகழ்களா செயல்களுக்கு தரப்படும் அதே
முக்கியதுவத்தை வருங்கால கட்டற்ற மென்பொருள் ஆக்கும் திட்டதிர்காக தருவது மிகவும் கடினம்.
அதேபோல் பின்னர் திருத்திக் கொள்ளளாம் என்று என்னி வரவு செலவு கணக்கின் கட்டுபாட்டை காக்க
மேம்பாட்டாலர்கள் சில வற்றை இங்கும் அங்கும் விட்டுக்கொடுப்பதும் தவிர்க்க முடியாதது (வார்டு கன்னிங்காம் கூற்றின் படி, அவர்கள்
"தொழில்நுட்ப
கடனுக்கு" உள்ளாகின்றனர்).
இதனால் கட்டற்ற மென்பொருளாக மாற்ற நினைக்கும் போது, உடனடியாக கீழ் வரும்
விஷயங்களை கவணிக்க நேரிடும்:
வாடிக்கையாளர் சார்ந்த கட்டமைப்பு அல்லது கடவுச்சொல்கள்
குறியீடுகளில் பயன் படுத்த பட்டு உள்ளது;
பயன் பாட்டில் உள்ள(மற்றும் இரகசிய) தகவள்களை கொண்டு
உருவாக்க பட்ட மாதிரி தரவுகள்;
பொதுவாக பகிர கூடாத மிக முக்கிய தகவள்கள் பிழை பதிவுகளில்
இருப்பது;
வாடிக்கையாளரின் புதிய கோரிக்கையை பற்றி உண்மையாக தரப்பட்ட குறியீட்டு விளக்க
கருத்துக்கள்;
அறிமுகம் இல்லாத பயனர்களுக்கு முற்றிலும் ஒத்து போகாத சில தனிப்பட்ட
கருத்துக்கள் ஆவண காப்பகங்களில் கசிந்து விடுவது;
கட்டற்ற மென்பொருள் உருவாக்கத்திர்க்கு எதிரான, தனிப்பட்ட மேம்பாடுகளுக்கு மட்டும் ஒத்து
போகும் (அல்லது அதர்க்கும் கூட ஒத்து போகாத) சார்புநிலை குறியீட்டு நூலகங்களின்
உரிமங்கள்;
தவரான வடிவத்தில் உருவாக்க பட்ட ஆவணங்கள் (உதாரணமாக, தனியுரிமை
பெற்று உங்கள் நிருவனம் பயன் படுத்தும் விக்கி), மற்றும் பொது வினியோகத்திற்கு ஒத்து
போகும் படி அவற்றை எளிதில் உருமாற்றம் செய்து தரும் மென்பொருகள் கூட இல்லாமல்
இருப்து.;
உங்கள் உள் பயன் பாட்டில் இருந்து மாற்றும் போது மட்டும் வெளிப்படும் ஒவ்வாத தொகுப்பு
சூழல்;
சுத்த செய்துவிட வேண்டும் என்று அனைவருக் அறிந்திருந்த கூறுநிலைமை மீறல்கள், இருந்தும்
யாரும் செய்து முடிக்காதவை
(இந்த பட்டியல் போய் கொண்டே இருக்கும்.)
அதில் சுத்தம் செய்வது மட்டும் பிரச்சனை இல்லை; சில நேரங்களில் எடுக்க பட வேண்டுயுள்ள
அதிகப்படியான முடிவுகளும்தான். உதாரணமாக, ஏதேனும் இரகசிய குறிப்புகள் குறியீட்டு களஞ்சியத்தில்
பதிவேற்ற பட்டு இருந்தால், அதை மட்டும் அகற்றி விட்டுவதா, அல்லது அனைத்து வரலாற்றுகளையும் சுத்தம்
செய்து தருவதா அல்லது அந்த பதிவை விட்டு விட்டு அதர்க்கு அடுத்து வரும் பதிவுகளில் இருந்து
("மேல் நீக்கப்பட்ட — top-skim" என்று சில நேரங்களில்
சொல்லப்படும்) பொது மக்களுக்கு வழங்குவதா போன்ற முடிவுகள் எடுக்க வேண்டி வரலாம். இதில் எதுவும்
தவரான அல்லது சரியான முறையும் இல்லை — மேலும் இங்கு அதுதான் பிரச்சனையே:
இப்பொழுது உங்களுக்கு இன்னும் ஒரு முடிவு உள்ளது மேலும் இன்னும் ஒரு முடிவும் எட்க்க வேண்டி உள்ளது.
சில திட்டங்களில் இந்த முடிவுகள் எடுக்க பட்டு இருதி வெளியீட்டுக்கு முன்பு பல முறை மாற்றி அமைக்கவும்
பட்டு உள்ளன. அத்தகைய வீனடிப்புகளும் செலவில் ஒரு பகுதியே.
காத்து இருப்பது வெரும் வெளிப்படுத்தும் நிகள்வை உன்டாக்கு கின்றது
உருவாக்க பட்ட குறியீட்டு மூலத்தை திரந்த மூலமாக்குவது என்பது அது ஒரு வெளிப்படுத்தும் நிகள்வை
உன்டாக்கும் என்ற இன்னும் ஒரு சிக்கலும் உள்ளது. குறியீட்டில் இருக்கும் எந்த ஒரு பிரச்சனையும்
(கூறுநிலைமை குறைக்க பட்ட இடங்கள், பாதுகாப்பு குறைபாடுகள், மற்றும் பல), பொதுவுடமை செய்வதால்
மொத்தமாக நுண்ணாய்வுக்கு வளங்கப்படுகின்றது — அத்தகைய திரந்த மூலமாக்கல்
தொழில் நுட்ப வலைப்பதிவுலகிற்கு உடனடியாக அந்த குறியீட்டை பகுத்தாய்ந்து என்ன கண்டு பிடிக்க முடியும்
என்ற ஆவலை தூண்டு கின்றது.
அதர்க்கு மாறாக துவக்கத்தில் இருந்தே திறந்த மூல திட்டமாக செயல் பட்டு வரும் திட்டதில்:
குறியீட்டு மாற்றம் ஒவ்வொன்றாக வந்து சேரும், எனவே எந்த சிக்கலும் அவை வரும்போதே தீர்க்கவும்படும்
(மேலும் அதை பலர் பார்வை இடுவதால், அவை மிக விரைவில் கண்டுபிடிக்க படுகிண்றன). பொது மக்களுக்கு குறைவாகவும், தொடர்ந்தும் வெளிக்காட்டப்படுவதால், உங்கள் மேம்படுத்தும் குழுவை எவரும்
அவ்வப்போது செய்யப்படும் குறைப்பு அல்லது தவறான குறியீட்டு பதிவுகளுக்காக குறை கூர மாட்டார்கள்.
அனைவருமே அதில் தொடர்ந்து பங்கு கொள்வதால்; நடைமுறை உலகில் இத்தகைய ஏற்ற தால்வுகள் தவிர்க்க
முடியாதவை. "FIXME" குறிப்புகள் மற்றும் பிழை பதிப்புகளின் வழியாக பதிவு செய்ய பட்டு அனைத்து
தொழில்நுட்ப கடன்கள் மற்றும் பாதுகாப்பு குறைபாடுகள் தீர்க்க படும் வரை நல்லது. இருப்பினும் அத்தகைய
பிரச்சனைகள் சிறிது சிறிதாய் உருவாக்கும் போது தோன்றாமல் திடீரென்று ஒரே நேரத்தில் வந்தால், அனுதாபமற்ற பார்வையாளர்கள் மிகக் கடுமையான மதிப்பீடுகளை வெளியிடுவர்.
(அரசாங்க மென்பொருள் திட்டங்களில் இந்தக் கவலைகள் இன்னும் வலுவாக இருக்கின்றன; மேலும்
விவரங்களுக்கு அரசு சார் திரந்த் மூல திட்டங்களை
துவங்குதல் என்ற பகுதியை -யில்
பருங்கள்.)
இவை அனைத்தும் இயல்பான தவருகள் என்பது ஒரு நல்ல செய்தி. அத்தகைய பிழைகளை தவிர்க்க
குறைவான செலவில் மிக எளிய வழி: முதலில் இருந்தே திரந்த மூல திட்டமாக இயக்குவதுதான்.
"திரந்த" என்றால் பின்வருபவை அனைத்தும், பொதுவான வடிவங்களில், திட்டதின் முதல் நாளில்
இருந்து வெளிப்படையாக அணுகத்தக்கவையாக இருக்கும்: குறியீட்டு களஞ்சியம், பிழை கண்காணிப்பான்,
வடிவமைப்பு ஆவணங்கள், பயபாட்டாலர்களின் ஆவனங்கள், விக்கி, மற்றும் மேம்பாட்டாலர்களின் விவாத
மன்றங்கள். அதன் அர்த்தம் குறியீடுகள் மற்றும் ஆவணங்களை அனைத்தும் கண்டிப்பாக கட்டற்ற
மென்பொருள் உரிமம் கொண்டு வளங்கப்பட்டு இருக்கும் என்பதாகும். அது மேலும் உங்கள் குழுவின் தின சரி
பணிகள் அனைத்தும் பொதுவாக அனைவரும் காணும்படி இருக்கும் என்பதாகவும் அர்த்தம் தருகிரது.
"திரந்த" என்பதன் பொருள் பின் வருபவை அல்லை: அரிமுகம் அற்றவர்களை
உங்கள் குறியீட்டு களஞ்சியத்தில் பதிவுகள் செய்ய அனுமதிப்பது (அவர்கள் அந்த குறியீடுகளை தங்கள்
களஞ்சியங்களில் பிரதி எடுத்து அதில் தடை இன்றி மாற்றங்களை மேற்க்கொள்ளலாம்); அனைவரையும்
உங்கள் பிழை கண்கானிப்பானில் பிழைகளை பதிவு செய்ய அனுமதிப்பது (நீங்கள் உங்கள் தர கட்டுபாடு
கொள்கையை விருப்பம் போல் அமைக்கலாம், அரிமுகம் இல்லாதவர்களை பதிவுகள் செய்ய அனுமதிக்க
வேண்டும் என்ற கட்டாயம் ஏதும் இல்லை); அப்படி அரிமுகம் அற்றவர்களை பதிவுகள் செய்ய அனுமதித்தாலும்
பதிவு செய்ய பட்ட அனைத்து பிழைகளையும் படித்து பதில் அழிக்க அனுமதிப்பது; மன்றங்களில் கேட்கப்படும்
கேள்விகளை படித்து பதில் அழிப்பது(அதை நீங்கள் தனிக்கை செய்தாலும்); அனைத்து இணைப்பு அல்லது
யோசனைகளையும் மீளாய்வு செய்வது, அப்படி செய்வது உங்கள் மேன்பாட்டு நேரத்தை விரயம் செய்யும்;
மற்றும் பல
அதை சரியாக புரிந்து கொள்வதேன்றால் நீங்கள் உங்கள் குறியீட்டை கட்டற்றதாக தரகின்றீர்கள்
உங்கள் நேரத்தை அல்ல. அவற்றில் ஒன்று என்னற்ற முறை பிரதி எடுக்க வல்லது மற்றது அப்படி அல்ல.
நீங்கள் வெளி பயனர்கள் மற்றும் மேம்பாட்டாலர்களுடன் எப்போது ஈடுபடவது திட்டதிர்கு உகந்தது என்று முடிவு
செய்ய வேண்டும். காலப்போக்கில் அது அவசியம் ஆகிரது, மேலும் இந்த புத்தகத்தின் பொரும் பகுதி அதை
எப்படி சிறப்பாக செய்ய வேண்டும் என்பதை கூரு கின்றது. இருப்பினும் அது முற்றிலும் உங்கள் கட்டுப்பாட்டில்
உள்ளது. கட்டற்ற வளர்ச்சி முறை இதை மாற்றுவது இல்லை, ஆயிலும் அந்த திட்டதில் செய்ய பட்ட
அனைத்தும் வருமுரைப்படி எப்படி கட்டற்ற திட்டதுடன் ஒத்து போகிறது என்பதை உருதி படுத்து கின்றது.
மாற்றத்தில் பருமனை உணர்ந்து எப்போது தனியுரிமை திட்டத்தை கட்டற்றதாக மாற்றுவது
முற்பகுதியில் குறிப்பிட்டதை போன்று, தனியுரிமை
திட்டதை கட்டற்றதாக மாற்றும் கடினமான சூழலை முதலில் தவிர்த்து விடுங்கள்; முடிந்த வரை கட்டற்றதாகவே
திட்டங்களை உருவாக்க முயலுங்கள். அப்படியும் தவிர்க்க முடியாமல் தனியுரிமை திட்டதை கட்டற்றதாக
மாற்ற வேண்டிய கட்டாயம் இருப்பின் அதில் ஏற்கனவே பனியாற்று பவர்களுக்கு பொரிய மாற்றம் வருகிறது
என்பதை நினைகூருங்கள்—மேலும் அதை அவர்களில் நிலையில் இருந்து புரிந்து கொள்ள முயற்சியும்
செய்யுங்கள்.
அவர்களுக்கு அந்த சூழல் எப்படி இருக்கும் என்பதை கற்பனை செய்து பாருங்கள்: பொதுவாக,
அனைத்து குறியீடுகள் மற்றும் வடிவமைப்பு முடிவுகளும் அந்த மென்பொருள் பற்றி தங்களை ஒத்த தெளிவுள்ள
குழுவால் எடுக்க பட்டு இருக்கும், அவர்கள் அனைவரும் ஒரே மாதிரியான மேலான்மையின் அழுத்ததில்
பனியாற்றி இருப்பார்கள், மேலும் அவர்களில் தனிப்பட்ட திரமைகள் மற்றும் குறைகளையும் நன்கு உனர்ந்து
இர்ப்பார்கள். இப்போது அவர்களை முற்றிலும் அரிமுகம் அற்ற, குறியீட்டினை மட்டும் வைத்து எத்தகைய
வர்த்தக அழுத்தம் சில முடிவுகளை எடுக்க கட்டாயப்படுத்தி இருக்கும் என்பதை பற்றி கவலை இன்றி
மீலாய்வுக்கு செய்பவர்களுக்கு ஏற்ற வகையில் குறியீடுகளை வெளிப்படுத்த சொல்கின்றீர்கள். அத்தகைய
புதியவர்கள் பல கேள்விகளை கேட்பார்கள், அந்த கேள்விகள் அதிக சிரதை கொண்டு உருவாக்கிஇருக்கும் ஆவணங்கள் இன்னும் போதுமானது இல்லை என்ற நினைப்பை
மேம்பாட்டாலர்களுக்கு தந்து விடும்(அதை தவிர்க்க இயலாதது). இவை அனைத்திர்கும் மேலாக, புதியவர்கள்
அனைவரும் முகம் தெரியாத அரிமுகம் அற்றவர்கள். உங்களில் ஒருவரேனும் தனது திறமை மீது நம்பிக்கை
குறைவாக வைத்திருப்பின், அவரின் குறியீடுகள்மீது மற்ற உடன் பனிபுரிபவரின் முன்பு மூன்றாம் நபர் குறைகளை
முன்வைப்பதால் எப்படி இருக்கும் என்று என்னி பாருங்கள். மிக துள்ளியமான குறியீடுகளை
உருவாக்குபவர்களின் குழுவாக உங்களை குழு இல்லை என்றால் இதனை தவிர்க்க இயலாது—இது
முதலில் அனைவருக்கும் நிகலலாம், அனைவரும் திரமை அற்ற உருவாக்குபவர்கள் என்பதால் அல்ல மாறாக
எந்த ஒரு குறியீட்டு நிரலும் குறிப்பிட்ட அளவைதான்டினால் அதில் பிழைகள் வருவதும் அதை உடன்
பனிபுரிபவர்கள் திரனாய்வு செய்து கண்டு பிடிப்பதும் இயல்பானதே.
( என்ற முத்தய பகுதியை
பாருங்கள்). அதே சமயம் புதியவர்கள் எவரும் அதிகம் குறியீடுகளை பங்களிப்பு செய்யாததால்
அவர்கள் அதிகம் பரீசீலணை செய்யப்படுவது இல்லை. உங்கள் உருவாக்குபவர்களுக்கு இது அனைத்து
குறைகளும் தங்களை நோக்கியே சொல்லப்படுவதாக தோன்றும். இதனால் அவர்களுக்குல் ஒரு முற்றுகை
மனோபாம் உருவாகி விடும்.
இதனை தவிர்க்க மிகவும் சிரந்த வழி அவர்கள் அனைவருக்கும் என்னவெல்லாம் எதிர் பாக்கலாம்
என்றும், ஆரம்பத்தில் இருக்கும் சங்கடமான சூழல் முற்றிலும் இயல்பானது மற்றும் காலம் செல்ல செல்ல அது
மேம்பாடு அடையும் என்பதையும் எடுத்து கூருதல். அவற்றில் சில திட்டதை திரந்த மூலமாக்கும் முன்பு
தனியாக அறிவுத்த பட வேண்டியவை. இருப்பினும் பொது மக்களுக்கு இது புதிதாக திரந்த மூலமாக்க பட்ட
திட்டம் என்பதையும் அதின் செயல் முறைகளில் முன்னேற்றம் காண சிறிது காலம் ஆகும் என்பதை
அரிவிக்கும் பட்டியலைதருவதும் நல்லது. இதன் மேலும் மிக சிரந்த செயல் முன் நின்று வழி நடத்துவதே.
உங்கள் மேம்பாட்டாலர்கள் புதியவர்கள் கேள்விகளுக்கு அதிக பதில் தராவிடில், அவர்களை அதிகம் பதில் கூர
சொல்வது மட்டும் பலன் தராது. அவர்களுக்கு எதற்கு பதில் கூர வேண்டும் எதை தவிர்க்க வேண்டும் என்று
தெறியாமல் இருக்கலாம், அல்லது குறியீட்டு பனியின் சுமைகளுக்கு இடையில் எப்படி வெளியுலகிர்க்கு பதில்
கூருவது என்று முன்னுரிமை படுத்த தெறியாமல் இருக்கலாம். நீங்கள் அதில் பங்கெடுத்து கொள்வதான்
மூலம் அவர்களை பங்கு பெற செய்வய முடியும். பொது அஞ்சல் பட்டியலில் பங்கெடுத்து கொண்டு அதில் சில
கேள்விகளுக்கு பதில் கூரவும் தவராதிர்கள். உங்களால் பதில் கூர முடியாத வற்றை அதில் சிரந்த ஒரு
மேம்பாட்டாலருக்கு வெலிப்படையாக முன் எடுத்து கூருங்கள்—அதர்க்கு பதிலோ அல்லது தீர்வோ
கிடைக்க பெரும் படி பின் தொடரவும் செய்யுங்கள். இது இயல்பாகவே சிறந்த மற்ற நீன்ட நாள்
மேம்பாட்டாலர்களை அத்தகைய செயல்களை தனிப்பட்ட விவாதம் செய்ய தூன்டிவிடும். உள்ளீடான அஞ்சல்
பட்டியலில் அத்தகைய விவாதங்களை இனம் கண்டு அதை பொது பட்டியலுக்கு மாற்றவும் அறிவுர்த்துங்கள்.
பலய தனியுரிம திட்டங்களை திரந்த மூலமாக மாற்றுவதில் சில நீன்ட கால சவால்களும் உள்ளன.
என்ற பகுதி எப்படி ஊதியம் பெரும் மற்றும் ஊதியம் அற்ற பனியாலர்களை கையால்வது என்பதையும், என்ற பகுதி பிர மென்பொருள் சார்ந்து எழுதப்பட்ட
குறியீடுகளை எப்படி சட்டப்படி கையால்வது என்பதையும் விவாதிக்கின்றன்.
அறிவித்தல்
திட்டம் அறிமுகம் செய்ய தயாரானவுடன்—முலுமையாக இல்லாவிடினும் அறிமுகம் செய்ய
தயாரானவுடன்—நீங்கள் வெளி உலகிற்கு அறிவிக்க தயாராகலாம்.
இது நீங்கள் எதிர் பார்ப்பதை விட மிக எழிதாகவே இருக்கும். பொதுவாக அதர்கு இரண்டு வகை
மன்றங்கள் உள்ளன: புதிய திட்டங்கள் பற்றிய அறிவிப்புகள் செய்யும் பொது மன்றங்கள் அல்லது உங்கள்
திட்டதிற்கு ஒத்த தலைப்புகள் பற்றிய அறிவிப்பு மன்றங்கள்.
freecode.com
ஒரு மிக சிறந்த மன்றம் — மேல் தட்டில் அமைந்த
புதிய திட்டப்பணியைச் சமர்ப்பிக்கவும் என்ற சுட்டியை இயங்கினால் போதும்.
ப்ரிகோடின் புதிய திட்டங்கள் அனைத்தும்
Slashdot.org என்ற மிகவும் பிரபலமான தளதில்
தானக உள் இனைக்க படும், அது விருப்ப உள்ள ஒருவரின் வாய்வழி செய்தியாக பரவும் வாய்ப்பை தருகின்றது.
(குறிப்பு: 2011 இல் மறு பெயரிடும் வரை ப்ரிகோட் Freshmeat.net என்று இருந்தது.) நீங்கள் உங்கள்
திட்டத்தை OhLoh.net இலும் பதிவிடலாம், இது
அனைத்து கட்டற்ற மென்பொருள் பற்றிய விவரம் கொண்ட தகவல் கலஞ்சியத்திர்கு நிகரானது.
(reddit.com/r/technology
இன் பிரிவான
news.ycombinator.com
பேன்றவற்றின் முதல் பக்கதில் பதியப்பட்டு வாய்வழி செய்தி / முன்னேற்றம் கண்ட திட்டங்களும் சில உள்ளன.
அப்படி பட்ட தளங்களின் முதல் பக்கதில் பதிவிடப்படுவது உங்களு திட்டதிர்க்கு நல்ல செய்தி என்றாலும்,
நான் வியபார போட்டிகளில் இருக்கும் எதை பற்றியும் சிரபித்து கூர விரும்பவில்லை. மிக அதிக அளவில்
வீன் விளம்பரம் இல்லாவன்னம் உங்கள் தனிப்பட்ட முடிவுகளை சார்ந்து செயல் படுங்கள்.)
தலைப்பு சார்ந்த மன்றங்கள்தான் பொதுவாக அதிகம் கவணம் ஈங்கு கூடியவை. உங்கள் திட்டம்
பற்றிய அறிவிப்பு எந்த மன்றத்தில் அல்லது அஞ்சல் பட்டியலில் ஒரு தலைப்பாக இருக்கும் என்பதை
என்னிப்பாருங்கள் — நீங்கள் அவற்றில் சில வற்றில் சந்ததாரராகவும்
இருக்கலாம் — பின்பு அதில் பதிவிடுங்கள். அனைத்து மன்றங்களிலும் கண்டிப்பாக
ஒரே ஒரு பதிவு மட்டும் செய்யுங்கள், மேலும் அதைபற்றிய மேலும் விவரங்களுக்கு
உங்கள் தனிப்பட்ட தளத்தின் மன்றத்தை அனுகும் படி செய்யுங்கள் (மின் அஞ்சல் அனுப்பும் போது
Reply-to தலைப்பை பயன் படுத்துவதால் இதை செய்யலாம்). உங்கள்
அறிவிப்பு சுருக்கமாகவும் மற்றும் சொல்ல வந்ததை சொல்லும் படியும் இருக்க வேண்டும், மேலும் அதன்
தலைப்பு இது ஒரு புதிய திட்ட அறிவிப்பு என்பதை கூர வேண்டும்:
To: discuss@some.forum.about.search.indexers
Subject: [ANN] Scanley, a new full-text indexer project.
Reply-to: dev@scanley.org
This is a one-time post to announce the creation of the Scanley
project, an open source full-text indexer and search engine with a
rich API, for use by programmers in providing search services for
large collections of text files. Scanley is now running code, is
under active development, and is looking for both developers and
testers.
Home page: http://www.scanley.org/
Features:
- Searches plain text, HTML, and XML
- Word or phrase searching
- (planned) Fuzzy matching
- (planned) Incremental updating of indexes
- (planned) Indexing of remote web sites
- (planned) Long-distance mind-reading
Requirements:
- Python 3.2 or higher
- SQLite 3.8.1 or higher
For more information, please come find us at scanley.org!
Thank you,
-J. Random
(பின்வரும் வெளியீடுகள் மற்றும் நிகழ்வுகளை எப்படி அறிவிப்பது என்பதை பற்றி அறிய
இன்
என்ற பகுதியை பாருக்கல்.)
இயங்க கூடிய குறியீடுகளுடன் ஒரு திட்டதை துவங்குவதா அல்லது வடிவமைப்பு/விவாதம் நடைபெரும்
கட்டதிலேயே அறிவிப்பை செய்துவிடுவதால் பலன் அதிகம் கிடைங்குமா என்ற விவாதம் கட்டற்ற மென்பொருள்
உலகில் தொடர்ந்து நடந்து வருகின்றது. நான் இயங்க கூடிய குறியீடுகளுடன் ஒரு திட்டதை துவங்குவது
சிறந்தது என்று என்னி வந்தேன், அது வெற்றிகரமான திட்டங்களை விழையாட்டு பொறுல்களில் இருந்து பிரித்து
காட்டுகின்றது, மேலும் தீவிரமான மேம்பாட்டாலர்கள் ஏற்கனவே ஏதேனும் உபயோகமாக செய்யும் மென்பொருள்
மீதுதான் அதிகம் அக்கரை காட்டுகின்றனர்.
அது அடிப்படையில் தவராக போனது. ஸப்வேர்சன் திட்டதை, நாங்கள் விருப்பமான மற்றும் நன்கு
தொடர்பில் உள்ள மேம்பாட்டாலர்கள் கொண்டு வடிவமைப்பு ஆவணத்துடன் மட்டும், முற்றிலும் குறியீடுகள் ஏதும்
இல்லாமல் துவங்கினோம். எனக்கு முற்றிலும் ஆச்சிரியந்தரும் வகையில் அந்த
திட்டம் துவக்கம் முதலே சுறுசுறுப்பாக பங்காற்றுபவர்கள் பலரை பெற்றது மேலும் அது சிறிது இயங்க துவங்கும்
முன்பே ஆழமாக ஈடுபாடு கொண்ட தன்னார்வளர்கள் சிலரும் இருந்தனர். ஸப்வேர்சன் மட்டும் அல்ல
மோசில்லா திட்டமும் முற்றிலும் இயங்க கூடிய குறியீடுகள் இன்றி வடிவமைப்பு காலத்திலேயே துவங்க
பட்டதோடு இன்று மிகவும் பிரபலமாக மற்றும் வெற்றகரமாக உள்ளது.
இந்த சான்றுகள் மற்றும் பல உதாரணங்களால், இயங்க கூடிய குறியீட்டுடன் ஒரு திட்டதை துவங்க
வேண்டும் என்ற எனது வலியுறுத்தலில் இருந்து நான் பின் வாங்க நேர்ந்தது. இருப்பினும் இயங்க கூடிய
குறியீடுகள் வெற்றிக்கு மிக சிறந்த அடித்தலமா உள்ளன, மேலும் அதுவரை அறிவிப்பை தல்லி போடுவது ஒரு
நல்ல வழிகாட்டலாக இருக்கும்.அறிவித்தல் என்பது உங்கள்
திட்ட குறியீடுகளை திரந்த மூலமாக செய்து பின் நீன்ட இடைவேளைக்கு பின்பு வருவாது என்பதை கவணத்தில்
கொல்க. எனது அறிவிப்பு செய்வது பற்றிய ஆலோசனையை திரந்த மூலமாக்குவதர்க்கு தந்ததாக என்ன
வேண்டாம் — உங்கள் திட்டம் துவக்கம் முதலே திரந்த மூலமாக மற்றும் போது மக்களால்
அனுகக் கூடியதாக அதன் ஆரம்பம் முதலே இருக்க வேண்டியது அவசியம், மேலும் அது அதனை அறிவிப்பு
செய்வதில் இருந்து முற்றிலும் வேரு பட்டது. மேலும் விரங்களுக்கு
ஐ பார்க்க. அப்படி இருந்தும்
சில சமயங்களில் முதலில் அறிவிப்பு செய்வதும் அர்த்தமுள்ளதாக உள்ளது. நன்கு உருவாக்க பட்ட
வடிவமைப்பு ஆவணம் அல்லது ஒரு வகையான குறியீட்டு கட்டமைப்பேனும் அவசிம் என்றே
கருதுகிறேன்—அது கண்டிப்பாக மக்களில் விமர்சனத்தை பொருத்து மாறுபடும் என்றாலும் நல்லென்னம்
மட்டும் இன்றி அவர்கள் ஈடுபாடு காட்ட ஏதேமும் உருதியாக மற்றும் பயனுல்ல ஒன்றேனும் இருக்க
வேண்டும்.
நீங்கள் எப்போது அறிவிப்பு செய்தாலும் உடனடியாக கும்பலாக மேம்பாட்டாலர்கள் தன்னார்வலர்களாக கிட்ப்பார்கள் என்று நினைக்காதீர்கள். பொதுவாக அறிவிப்பு செய்த உடன் ஒரு சில சாதாரண வினாக்கள் ம்ற்றும் அஞ்சல் பட்டியலில் சிலர் சந்தா பெருவாது மட்டுமே நடைபொரும் மேலும் மற்றவை முன்பு இருந்ததை போன்றே எந்த மாற்றமும் இன்றி இருக்கும். நாட்க்கள் செல்ல செல்ல புதியவர்கள் ம்ற்றும் பயனர்களீன் பங்களிப்பு அதிகரிப்பதை காணலாம். அறிவிப்பு ஒரு விதைத்தல் மட்டுமே. அந்த செய்தி பரவ மிக நீன்ட கால்ம ஆகலாம். உங்கள் திட்டதில் ஈடுபாடுபர்களுக்கு வெகுமதிகளை சீராக தருகையில், அந்த செய்தி பரவும், காரணம் அனைவரும் தாங்கள் கண்டுனற்ந்த நல்ல செய்திகளை பகிர்ந்து கொள்ல விரும்புவார்கள். அனைத்தும் நன்றாக அமைந்தால், அதிவேகமான தொலைத் தொடர்பு இணைப்புகள், அனைத்து விவாதங்கள் மற்றும் அனைவரின் பெயர்ம் கவணிக்க இயலாத மிக சிக்கலான சமூகமாக உங்கள் திட்டதை வளரச்செய்யும். அடுத்த அத்யாயம் அத்தகைய சூழலில் எப்படி பனியாற்றுவது என்பதை பற்றியது.