ಈ ವಾರ ಸೇಂಟ್ ಪೀಟರ್ಸ್ ಬರ್ಗ್ ನಲ್ಲಿ ಐಟಿ ಉತ್ಸವ ನಡೆಯಲಿದೆ . ಭಾಷಣಕಾರರಲ್ಲಿ ಒಬ್ಬರು ರಿಚರ್ಡ್ ಸ್ಟಾಲ್ಮನ್. ಉತ್ಸವದಲ್ಲಿ ಭಾಗವಹಿಸುತ್ತದೆ ಮತ್ತು ಉಚಿತ ಸಾಫ್ಟ್‌ವೇರ್ ವಿಷಯವನ್ನು ನಾವು ನಿರ್ಲಕ್ಷಿಸಲಾಗಲಿಲ್ಲ. ಅದಕ್ಕಾಗಿಯೇ ನಮ್ಮ ವರದಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಕರೆಯಲಾಗುತ್ತದೆ . ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಆಗಿ ಎಂಬಾಕ್ಸ್‌ನ ಅಭಿವೃದ್ಧಿಯ ಇತಿಹಾಸಕ್ಕೆ ಇದನ್ನು ಸಮರ್ಪಿಸಲಾಗುವುದು. ಈ ಲೇಖನದಲ್ಲಿ ನಾನು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಳ ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರುವ ಮುಖ್ಯ ವಿಚಾರಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ. ವರದಿಯಂತೆ ಲೇಖನವು ವೈಯಕ್ತಿಕ ಅನುಭವವನ್ನು ಆಧರಿಸಿದೆ.
ಓಪನ್ ಸೋರ್ಸ್ ಪದದ ವ್ಯಾಖ್ಯಾನದೊಂದಿಗೆ ಸರಳವಾದ ಯಾವುದನ್ನಾದರೂ ಪ್ರಾರಂಭಿಸೋಣ. ನಿಸ್ಸಂಶಯವಾಗಿ, ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಎನ್ನುವುದು ಪ್ರಾಜೆಕ್ಟ್‌ನ ಮೂಲ ಕೋಡ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಅನುಮತಿಸುವ ಪರವಾನಗಿಗಳಲ್ಲಿ ಒಂದನ್ನು ಹೊಂದಿರುವ ಯೋಜನೆಯಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ತೆರೆದ ಯೋಜನೆ ಎಂದರೆ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೆವಲಪರ್‌ಗಳು ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಬಹುದು. ಅಂದರೆ, ಕೆಲವು ಕಂಪನಿ ಅಥವಾ ಡೆವಲಪರ್ ಅದರ ಉತ್ಪನ್ನದ ಕೋಡ್ ಅನ್ನು ಭಾಗಶಃ ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಕಟಿಸಿದರೆ, ಇದು ಇನ್ನೂ ಈ ಉತ್ಪನ್ನವನ್ನು ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಆಗಿ ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಯಾವುದೇ ಪ್ರಾಜೆಕ್ಟ್ ಚಟುವಟಿಕೆಯು ಕೆಲವು ರೀತಿಯ ಫಲಿತಾಂಶಕ್ಕೆ ಕಾರಣವಾಗಬೇಕು, ಮತ್ತು ಯೋಜನೆಯ ಮುಕ್ತತೆಯು ಈ ಫಲಿತಾಂಶವನ್ನು ಅಭಿವರ್ಧಕರು ಮಾತ್ರ ಬಳಸುವುದಿಲ್ಲ ಎಂದು ಸೂಚಿಸುತ್ತದೆ.
ಮುಕ್ತ ಪರವಾನಗಿಗಳ ಸಮಸ್ಯೆಗಳನ್ನು ನಾವು ಸ್ಪರ್ಶಿಸುವುದಿಲ್ಲ. ಇದು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ಸಂಕೀರ್ಣವಾದ ವಿಷಯವಾಗಿದ್ದು, ಆಳವಾದ ತನಿಖೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ. ಈ ವಿಷಯದ ಬಗ್ಗೆ ಸಾಕಷ್ಟು ಉತ್ತಮ ಲೇಖನಗಳು ಮತ್ತು ವಸ್ತುಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ. ಆದರೆ ನಾನು ಹಕ್ಕುಸ್ವಾಮ್ಯ ಕ್ಷೇತ್ರದಲ್ಲಿ ಪರಿಣಿತನಲ್ಲದ ಕಾರಣ, ಪರವಾನಗಿಯು ಯೋಜನೆಯ ಗುರಿಗಳನ್ನು ಪೂರೈಸಬೇಕು ಎಂದು ನಾನು ಹೇಳುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ಎಂಬಾಕ್ಸ್‌ಗಾಗಿ GPL ಪರವಾನಗಿಗಿಂತ BSD ಆಯ್ಕೆಯು ಆಕಸ್ಮಿಕವಲ್ಲ.
ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸಬೇಕು ಮತ್ತು ತೆರೆದ ಮೂಲ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಬೇಕು ಎಂಬ ಅಂಶವು ಯೋಜನೆಯನ್ನು ವಿತರಿಸಲಾಗಿದೆ ಎಂದು ಸೂಚಿಸುತ್ತದೆ. ಕೇಂದ್ರೀಕೃತ ನಿರ್ವಹಣೆಯೊಂದಿಗೆ ಯೋಜನೆಗೆ ಹೋಲಿಸಿದರೆ ಅದನ್ನು ನಿರ್ವಹಿಸುವುದು, ಸಮಗ್ರತೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಕಾಪಾಡಿಕೊಳ್ಳುವುದು ಹೆಚ್ಚು ಕಷ್ಟ. ಒಂದು ಸಮಂಜಸವಾದ ಪ್ರಶ್ನೆ ಉದ್ಭವಿಸುತ್ತದೆ: ಏಕೆ ತೆರೆದ ಯೋಜನೆಗಳು? ಉತ್ತರವು ವಾಣಿಜ್ಯ ಕಾರ್ಯಸಾಧ್ಯತೆಯ ಪ್ರದೇಶದಲ್ಲಿದೆ; ನಿರ್ದಿಷ್ಟ ವರ್ಗದ ಯೋಜನೆಗಳಿಗೆ, ಈ ವಿಧಾನದ ಪ್ರಯೋಜನಗಳು ವೆಚ್ಚವನ್ನು ಮೀರಿಸುತ್ತದೆ. ಅಂದರೆ, ಇದು ಎಲ್ಲಾ ಯೋಜನೆಗಳಿಗೆ ಸೂಕ್ತವಲ್ಲ ಮತ್ತು ಮುಕ್ತ ವಿಧಾನವು ಸಾಮಾನ್ಯವಾಗಿ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ತೆರೆದ ತತ್ವದ ಆಧಾರದ ಮೇಲೆ ವಿದ್ಯುತ್ ಸ್ಥಾವರ ಅಥವಾ ವಿಮಾನಕ್ಕಾಗಿ ನಿಯಂತ್ರಣ ವ್ಯವಸ್ಥೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು ಕಲ್ಪಿಸುವುದು ಕಷ್ಟ. ಇಲ್ಲ, ಸಹಜವಾಗಿ, ಅಂತಹ ವ್ಯವಸ್ಥೆಗಳು ತೆರೆದ ಯೋಜನೆಗಳ ಆಧಾರದ ಮೇಲೆ ಮಾಡ್ಯೂಲ್ಗಳನ್ನು ಒಳಗೊಂಡಿರಬೇಕು, ಏಕೆಂದರೆ ಇದು ಹಲವಾರು ಪ್ರಯೋಜನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಆದರೆ ಅಂತಿಮ ಉತ್ಪನ್ನಕ್ಕೆ ಯಾರಾದರೂ ಜವಾಬ್ದಾರರಾಗಿರಬೇಕು. ಸಿಸ್ಟಮ್ ಸಂಪೂರ್ಣವಾಗಿ ತೆರೆದ ಯೋಜನೆಗಳ ಕೋಡ್ ಅನ್ನು ಆಧರಿಸಿದ್ದರೂ ಸಹ, ಡೆವಲಪರ್, ಎಲ್ಲವನ್ನೂ ಒಂದೇ ಸಿಸ್ಟಮ್ಗೆ ಪ್ಯಾಕ್ ಮಾಡಿ ಮತ್ತು ನಿರ್ದಿಷ್ಟ ನಿರ್ಮಾಣಗಳು ಮತ್ತು ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ಮಾಡಿದ ನಂತರ, ಮೂಲಭೂತವಾಗಿ ಅದನ್ನು ಮುಚ್ಚುತ್ತದೆ. ಕೋಡ್ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರಬಹುದು.
ತೆರೆದ ಮೂಲ ಯೋಜನೆಗಳನ್ನು ರಚಿಸುವುದರಿಂದ ಅಥವಾ ಕೊಡುಗೆ ನೀಡುವುದರಿಂದ ಈ ವ್ಯವಸ್ಥೆಗಳಿಗೆ ಸಾಕಷ್ಟು ಪ್ರಯೋಜನಗಳಿವೆ. ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಅಂತಿಮ ಸಿಸ್ಟಮ್ ಕೋಡ್ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರಬಹುದು. ಏಕೆ, ಏಕೆಂದರೆ ಸಿಸ್ಟಮ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಲು ಯಾರಾದರೂ ಅದೇ ವಿಮಾನವನ್ನು ಹೊಂದಿರುವುದು ಅಸಂಭವವಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಇದು ನಿಜ, ಆದರೆ ಕೋಡ್‌ನ ಕೆಲವು ವಿಭಾಗಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಬಯಸುವ ಯಾರಾದರೂ ಇರಬಹುದು ಅಥವಾ, ಉದಾಹರಣೆಗೆ, ಬಳಸುತ್ತಿರುವ ಲೈಬ್ರರಿಯನ್ನು ಸರಿಯಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿಲ್ಲ ಎಂದು ಯಾರಾದರೂ ಕಂಡುಹಿಡಿಯಬಹುದು.
ಕಂಪನಿಯು ಸಿಸ್ಟಮ್ನ ಕೆಲವು ಮೂಲಭೂತ ಭಾಗವನ್ನು ಪ್ರತ್ಯೇಕ ಯೋಜನೆಗೆ ನಿಯೋಜಿಸಿದರೆ ಇನ್ನೂ ಹೆಚ್ಚಿನ ಪ್ರಯೋಜನವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಕೆಲವು ರೀತಿಯ ಡೇಟಾ ವಿನಿಮಯ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಬೆಂಬಲಿಸಲು ಲೈಬ್ರರಿ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪ್ರೋಟೋಕಾಲ್ ನಿರ್ದಿಷ್ಟ ವಿಷಯದ ಪ್ರದೇಶಕ್ಕೆ ನಿರ್ದಿಷ್ಟವಾಗಿದ್ದರೂ ಸಹ, ನೀವು ಈ ಪ್ರದೇಶದ ಇತರ ಕಂಪನಿಗಳೊಂದಿಗೆ ಸಿಸ್ಟಮ್ನ ಈ ತುಣುಕನ್ನು ನಿರ್ವಹಿಸುವ ವೆಚ್ಚವನ್ನು ಹಂಚಿಕೊಳ್ಳಬಹುದು. ಹೆಚ್ಚುವರಿಯಾಗಿ, ಸಾರ್ವಜನಿಕ ಡೊಮೇನ್‌ನಲ್ಲಿ ಸಿಸ್ಟಮ್ನ ಈ ಭಾಗವನ್ನು ಅಧ್ಯಯನ ಮಾಡುವ ತಜ್ಞರು ಅದನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸಲು ಕಡಿಮೆ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಅಂತಿಮವಾಗಿ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೆವಲಪರ್‌ಗಳು ಬಳಸುವ ಸ್ವತಂತ್ರ ಘಟಕವಾಗಿ ಒಂದು ತುಣುಕನ್ನು ಬೇರ್ಪಡಿಸುವುದರಿಂದ ಈ ಭಾಗವನ್ನು ಉತ್ತಮಗೊಳಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ನಾವು ಪರಿಣಾಮಕಾರಿ API ಗಳನ್ನು ನೀಡಬೇಕಾಗಿದೆ, ದಸ್ತಾವೇಜನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ ಮತ್ತು ಪರೀಕ್ಷಾ ವ್ಯಾಪ್ತಿಯನ್ನು ಸುಧಾರಿಸುವ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುವುದಿಲ್ಲ.
ತೆರೆದ ಮೂಲ ಯೋಜನೆಗಳನ್ನು ರಚಿಸದೆಯೇ ಕಂಪನಿಯು ವಾಣಿಜ್ಯ ಪ್ರಯೋಜನಗಳನ್ನು ಪಡೆಯಬಹುದು; ಕಂಪನಿಯಲ್ಲಿ ಬಳಸುವ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಯೋಜನೆಗಳಲ್ಲಿ ಅದರ ತಜ್ಞರು ಭಾಗವಹಿಸಲು ಸಾಕು. ಎಲ್ಲಾ ನಂತರ, ಎಲ್ಲಾ ಪ್ರಯೋಜನಗಳು ಉಳಿದಿವೆ: ಉದ್ಯೋಗಿಗಳು ಯೋಜನೆಯನ್ನು ಚೆನ್ನಾಗಿ ತಿಳಿದಿದ್ದಾರೆ, ಆದ್ದರಿಂದ ಅವರು ಅದನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಬಳಸುತ್ತಾರೆ, ಕಂಪನಿಯು ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯ ದಿಕ್ಕಿನ ಮೇಲೆ ಪ್ರಭಾವ ಬೀರಬಹುದು ಮತ್ತು ರೆಡಿಮೇಡ್, ಡೀಬಗ್ ಮಾಡಿದ ಕೋಡ್‌ನ ಬಳಕೆಯು ಕಂಪನಿಯ ವೆಚ್ಚವನ್ನು ನಿಸ್ಸಂಶಯವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಗಳನ್ನು ರಚಿಸುವ ಪ್ರಯೋಜನಗಳು ಅಲ್ಲಿಗೆ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ. ವ್ಯಾಪಾರದ ಅಂತಹ ಪ್ರಮುಖ ಅಂಶವನ್ನು ಮಾರ್ಕೆಟಿಂಗ್ ಎಂದು ತೆಗೆದುಕೊಳ್ಳೋಣ. ಅವನಿಗೆ, ಇದು ಮಾರುಕಟ್ಟೆಯ ಅವಶ್ಯಕತೆಗಳನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುವ ಉತ್ತಮ ಸ್ಯಾಂಡ್‌ಬಾಕ್ಸ್ ಆಗಿದೆ.
ಮತ್ತು ಸಹಜವಾಗಿ, ಯಾವುದೇ ವಿಶೇಷತೆಯ ವಾಹಕ ಎಂದು ನಿಮ್ಮನ್ನು ಘೋಷಿಸಲು ಮುಕ್ತ ಮೂಲ ಯೋಜನೆಯು ಪರಿಣಾಮಕಾರಿ ಮಾರ್ಗವಾಗಿದೆ ಎಂಬುದನ್ನು ನಾವು ಮರೆಯಬಾರದು. ಕೆಲವು ಸಂದರ್ಭಗಳಲ್ಲಿ, ಮಾರುಕಟ್ಟೆಯನ್ನು ಪ್ರವೇಶಿಸಲು ಇದು ಏಕೈಕ ಮಾರ್ಗವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ಎಂಬಾಕ್ಸ್ RTOS ಅನ್ನು ರಚಿಸುವ ಯೋಜನೆಯಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು. ಬಹಳಷ್ಟು ಸ್ಪರ್ಧಿಗಳು ಇದ್ದಾರೆ ಎಂದು ವಿವರಿಸಲು ಬಹುಶಃ ಅಗತ್ಯವಿಲ್ಲ. ಸಮುದಾಯವನ್ನು ರಚಿಸದೆಯೇ, ಯೋಜನೆಯನ್ನು ಅಂತಿಮ ಬಳಕೆದಾರರಿಗೆ ತರಲು ನಾವು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ, ಅಂದರೆ, ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಡೆವಲಪರ್‌ಗಳು ಯೋಜನೆಯನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಲು.
ಮುಕ್ತ ಮೂಲ ಯೋಜನೆಯಲ್ಲಿ ಸಮುದಾಯವು ಪ್ರಮುಖವಾಗಿದೆ. ಯೋಜನಾ ನಿರ್ವಹಣಾ ವೆಚ್ಚವನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಲು, ಯೋಜನೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಮತ್ತು ಬೆಂಬಲಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಸಮುದಾಯವಿಲ್ಲದೆ ಯಾವುದೇ ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಇಲ್ಲ ಎಂದು ನಾವು ಹೇಳಬಹುದು.
ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಸಮುದಾಯವನ್ನು ಹೇಗೆ ರಚಿಸುವುದು ಮತ್ತು ನಿರ್ವಹಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಬಹಳಷ್ಟು ವಸ್ತುಗಳನ್ನು ಬರೆಯಲಾಗಿದೆ. ಈಗಾಗಲೇ ತಿಳಿದಿರುವ ಸಂಗತಿಗಳನ್ನು ಪುನಃ ಹೇಳದಿರಲು, ನಾನು ಎಂಬಾಕ್ಸ್ ಅನುಭವದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಉದಾಹರಣೆಗೆ, ಸಮುದಾಯವನ್ನು ರಚಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಬಹಳ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವಾಗಿದೆ. ಅಂದರೆ, ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಸಮುದಾಯವನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂದು ಹಲವರು ಹೇಳುತ್ತಾರೆ, ಆದರೆ ಅದರ ಸೃಷ್ಟಿಯ ಕ್ಷಣಗಳನ್ನು ಕೆಲವೊಮ್ಮೆ ಕಡೆಗಣಿಸಲಾಗುತ್ತದೆ, ಇದನ್ನು ನೀಡಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ.
ಓಪನ್ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಸಮುದಾಯವನ್ನು ರಚಿಸುವಾಗ ಮುಖ್ಯ ನಿಯಮವೆಂದರೆ ಯಾವುದೇ ನಿಯಮಗಳಿಲ್ಲ. ನನ್ನ ಪ್ರಕಾರ ಯಾವುದೇ ಸಾರ್ವತ್ರಿಕ ನಿಯಮಗಳಿಲ್ಲ, ಬೆಳ್ಳಿ ಗುಂಡು ಇಲ್ಲದಂತೆ, ಯೋಜನೆಗಳು ತುಂಬಾ ವಿಭಿನ್ನವಾಗಿರುವುದರಿಂದ ಮಾತ್ರ. js ಲಾಗಿಂಗ್ ಲೈಬ್ರರಿ ಮತ್ತು ಕೆಲವು ಹೆಚ್ಚು ವಿಶೇಷವಾದ ಡ್ರೈವರ್‌ಗಾಗಿ ಸಮುದಾಯವನ್ನು ರಚಿಸುವಾಗ ನೀವು ಅದೇ ನಿಯಮಗಳನ್ನು ಬಳಸಬಹುದು ಎಂಬುದು ಅಸಂಭವವಾಗಿದೆ. ಇದಲ್ಲದೆ, ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯ ವಿವಿಧ ಹಂತಗಳಲ್ಲಿ (ಮತ್ತು ಆದ್ದರಿಂದ ಸಮುದಾಯ), ನಿಯಮಗಳು ಬದಲಾಗುತ್ತವೆ.
ಎಂಬಾಕ್ಸ್ ವಿದ್ಯಾರ್ಥಿ ಯೋಜನೆಯಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು ಏಕೆಂದರೆ ಇದು ಸಿಸ್ಟಮ್ಸ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ವಿಭಾಗದಿಂದ ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದೆ. ವಾಸ್ತವವಾಗಿ, ನಾವು ಬೇರೆ ಸಮುದಾಯವನ್ನು ಪ್ರವೇಶಿಸುತ್ತಿದ್ದೇವೆ. ಈ ಸಮುದಾಯದ ಭಾಗವಹಿಸುವವರು, ವಿದ್ಯಾರ್ಥಿಗಳು, ಉತ್ತಮ ಕೈಗಾರಿಕಾ ಅಭ್ಯಾಸದಲ್ಲಿ ಅವರ ವಿಶೇಷತೆ, ಸಿಸ್ಟಮ್ ಪ್ರೋಗ್ರಾಮಿಂಗ್, ಕೋರ್ಸ್‌ವರ್ಕ್ ಮತ್ತು ಡಿಪ್ಲೊಮಾ ಕ್ಷೇತ್ರದಲ್ಲಿ ವೈಜ್ಞಾನಿಕ ಕೆಲಸದಲ್ಲಿ ನಾವು ಆಸಕ್ತಿ ವಹಿಸಬಹುದು. ಅಂದರೆ, ಸಮುದಾಯವನ್ನು ಸಂಘಟಿಸುವ ಮೂಲಭೂತ ನಿಯಮಗಳಲ್ಲಿ ಒಂದನ್ನು ನಾವು ಅನುಸರಿಸಿದ್ದೇವೆ: ಸಮುದಾಯದ ಸದಸ್ಯರು ಏನನ್ನಾದರೂ ಸ್ವೀಕರಿಸಬೇಕು ಮತ್ತು ಈ ಬೆಲೆ ಭಾಗವಹಿಸುವವರ ಕೊಡುಗೆಗೆ ಅನುಗುಣವಾಗಿರಬೇಕು.
ಎಂಬಾಕ್ಸ್‌ನ ಮುಂದಿನ ಹಂತವು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಬಳಕೆದಾರರ ಹುಡುಕಾಟವಾಗಿದೆ. ಬಳಕೆದಾರರು ಓಪನ್ ಸೋರ್ಸ್ ಸಮುದಾಯದಲ್ಲಿ ಪೂರ್ಣ ಭಾಗವಹಿಸುವವರು ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಬಹಳ ಮುಖ್ಯ. ಡೆವಲಪರ್‌ಗಳಿಗಿಂತ ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಬಳಕೆದಾರರಿದ್ದಾರೆ. ಮತ್ತು ಯೋಜನೆಗೆ ಕೊಡುಗೆದಾರರಾಗಲು ಬಯಸುವ ಸಲುವಾಗಿ, ಅವರು ಮೊದಲು ಅದನ್ನು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಬಳಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ.
ಎಂಬಾಕ್ಸ್‌ನ ಮೊದಲ ಬಳಕೆದಾರರು ಸೈದ್ಧಾಂತಿಕ ಸೈಬರ್ನೆಟಿಕ್ಸ್ ವಿಭಾಗ. ಲೆಗೊ ಮೈಂಡ್‌ಸ್ಟಾರ್ಮ್‌ಗಾಗಿ ಪರ್ಯಾಯ ಫರ್ಮ್‌ವೇರ್ ರಚಿಸಲು ಅವರು ಸಲಹೆ ನೀಡಿದರು. ಮತ್ತು ಅವರು ಇನ್ನೂ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರಾಗಿದ್ದರೂ (ನಾವು ಅವರನ್ನು ವೈಯಕ್ತಿಕವಾಗಿ ಭೇಟಿಯಾಗಬಹುದು ಮತ್ತು ಅವರಿಗೆ ಬೇಕಾದುದನ್ನು ಚರ್ಚಿಸಬಹುದು). ಆದರೆ ಇದು ಇನ್ನೂ ಉತ್ತಮ ಅನುಭವವಾಗಿತ್ತು. ಉದಾಹರಣೆಗೆ, ನಾವು ಇತರರಿಗೆ ತೋರಿಸಬಹುದಾದ ಡೆಮೊಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ರೋಬೋಟ್‌ಗಳು ವಿನೋದ ಮತ್ತು ಗಮನವನ್ನು ಸೆಳೆಯುತ್ತವೆ. ಪರಿಣಾಮವಾಗಿ, ಎಂಬಾಕ್ಸ್ ಎಂದರೇನು ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ಕೇಳಲು ಪ್ರಾರಂಭಿಸಿದ ನಿಜವಾದ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಬಳಕೆದಾರರನ್ನು ನಾವು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ.
ಈ ಹಂತದಲ್ಲಿ, ನಾವು ದಾಖಲಾತಿಗಳ ಬಗ್ಗೆ, ಬಳಕೆದಾರರೊಂದಿಗೆ ಸಂವಹನ ವಿಧಾನಗಳ ಬಗ್ಗೆ ಯೋಚಿಸಬೇಕಾಗಿತ್ತು. ಇಲ್ಲ, ಖಂಡಿತವಾಗಿಯೂ, ನಾವು ಈ ಪ್ರಮುಖ ವಿಷಯಗಳ ಬಗ್ಗೆ ಮೊದಲು ಯೋಚಿಸಿದ್ದೇವೆ, ಆದರೆ ಇದು ಅಕಾಲಿಕವಾಗಿತ್ತು ಮತ್ತು ಸಕಾರಾತ್ಮಕ ಪರಿಣಾಮವನ್ನು ನೀಡಲಿಲ್ಲ. ಪರಿಣಾಮವು ಸಾಕಷ್ಟು ಋಣಾತ್ಮಕವಾಗಿತ್ತು. ನಾನು ನಿಮಗೆ ಒಂದೆರಡು ಉದಾಹರಣೆಗಳನ್ನು ನೀಡುತ್ತೇನೆ. ನಾವು googlecode ಅನ್ನು ಬಳಸಿದ್ದೇವೆ, ಅದರ ವಿಕಿ ಬಹುಭಾಷಾವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ನಾವು ಹಲವಾರು ಭಾಷೆಗಳಲ್ಲಿ ಪುಟಗಳನ್ನು ರಚಿಸಿದ್ದೇವೆ, ಇಂಗ್ಲಿಷ್ ಮತ್ತು ರಷ್ಯನ್ ಮಾತ್ರವಲ್ಲ, ಅದರಲ್ಲಿ ನಾವು ಸಂವಹನ ನಡೆಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ, ಆದರೆ ಜರ್ಮನ್ ಮತ್ತು ಸ್ಪ್ಯಾನಿಷ್ ಕೂಡ. ಪರಿಣಾಮವಾಗಿ, ಈ ಭಾಷೆಗಳಲ್ಲಿ ಕೇಳಿದಾಗ ಇದು ತುಂಬಾ ಹಾಸ್ಯಾಸ್ಪದವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ನಾವು ಉತ್ತರಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ. ಅಥವಾ ಅವರು ದಸ್ತಾವೇಜನ್ನು ಬರೆಯುವ ಮತ್ತು ಕಾಮೆಂಟ್ ಮಾಡುವ ಬಗ್ಗೆ ನಿಯಮಗಳನ್ನು ಪರಿಚಯಿಸಿದರು, ಆದರೆ API ಸಾಕಷ್ಟು ಬಾರಿ ಮತ್ತು ಗಮನಾರ್ಹವಾಗಿ ಬದಲಾದ ಕಾರಣ, ನಮ್ಮ ದಸ್ತಾವೇಜನ್ನು ಹಳೆಯದಾಗಿದೆ ಮತ್ತು ಅದು ಸಹಾಯ ಮಾಡುವುದಕ್ಕಿಂತ ಹೆಚ್ಚು ತಪ್ಪುದಾರಿಗೆಳೆಯುತ್ತಿದೆ ಎಂದು ತಿಳಿದುಬಂದಿದೆ.
ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ಎಲ್ಲಾ ಪ್ರಯತ್ನಗಳು, ತಪ್ಪು ಸಹ, ಬಾಹ್ಯ ಬಳಕೆದಾರರ ನೋಟಕ್ಕೆ ಕಾರಣವಾಯಿತು. ಮತ್ತು ವಾಣಿಜ್ಯ ಗ್ರಾಹಕರು ಸಹ ಕಾಣಿಸಿಕೊಂಡರು, ಅವರು ತಮ್ಮದೇ ಆದ RTOS ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕೆಂದು ಬಯಸಿದ್ದರು. ಮತ್ತು ನಾವು ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಮಗೆ ಅನುಭವ ಮತ್ತು ಕೆಲವು ಅಡಿಪಾಯವಿದೆ. ಇಲ್ಲಿ ನೀವು ಒಳ್ಳೆಯ ಮತ್ತು ಕೆಟ್ಟ ಕ್ಷಣಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಬೇಕು. ನಾನು ಕೆಟ್ಟವರೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತೇನೆ. ಅನೇಕ ಅಭಿವರ್ಧಕರು ವಾಣಿಜ್ಯ ಆಧಾರದ ಮೇಲೆ ಈ ಯೋಜನೆಯಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದರಿಂದ, ಸಮುದಾಯವು ಈಗಾಗಲೇ ಸಾಕಷ್ಟು ಅಸ್ಥಿರವಾಗಿದೆ ಮತ್ತು ವಿಭಜನೆಯಾಗಿದೆ, ಇದು ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ. ಹೆಚ್ಚುವರಿ ಅಂಶವೆಂದರೆ ಯೋಜನೆಯ ನಿರ್ದೇಶನವನ್ನು ಒಬ್ಬ ವಾಣಿಜ್ಯ ಗ್ರಾಹಕರು ಹೊಂದಿಸಿದ್ದಾರೆ ಮತ್ತು ಅವರ ಗುರಿಯು ಯೋಜನೆಯ ಮುಂದಿನ ಅಭಿವೃದ್ಧಿಯಾಗಿರಲಿಲ್ಲ. ಕನಿಷ್ಠ ಇದು ಮುಖ್ಯ ಗುರಿಯಾಗಿರಲಿಲ್ಲ.
ಮತ್ತೊಂದೆಡೆ, ಹಲವಾರು ಸಕಾರಾತ್ಮಕ ಅಂಶಗಳಿವೆ. ನಾವು ನಿಜವಾಗಿಯೂ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಬಳಕೆದಾರರನ್ನು ಪಡೆದಿದ್ದೇವೆ. ಇದು ಗ್ರಾಹಕರು ಮಾತ್ರವಲ್ಲ, ಈ ವ್ಯವಸ್ಥೆಯನ್ನು ಉದ್ದೇಶಿಸಿರುವವರೂ ಸಹ. ಯೋಜನೆಯಲ್ಲಿ ಭಾಗವಹಿಸಲು ಪ್ರೇರಣೆ ಹೆಚ್ಚಿದೆ. ಎಲ್ಲಾ ನಂತರ, ನೀವು ಆಸಕ್ತಿದಾಯಕ ವ್ಯವಹಾರದಿಂದ ಹಣವನ್ನು ಗಳಿಸಬಹುದಾದರೆ, ಅದು ಯಾವಾಗಲೂ ಒಳ್ಳೆಯದು. ಮತ್ತು ಮುಖ್ಯವಾಗಿ, ಗ್ರಾಹಕರಿಂದ ಒಂದು ಆಸೆಯನ್ನು ನಾವು ಕೇಳಿದ್ದೇವೆ, ಅದು ಆ ಸಮಯದಲ್ಲಿ ನಮಗೆ ಹುಚ್ಚನಂತೆ ಕಾಣುತ್ತದೆ, ಆದರೆ ಈಗ ಎಂಬಾಕ್ಸ್‌ನ ಮುಖ್ಯ ಆಲೋಚನೆಯಾಗಿದೆ, ಅವುಗಳೆಂದರೆ, ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ಈಗಾಗಲೇ ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ ಕೋಡ್ ಅನ್ನು ಬಳಸುವುದು. ಈಗ ಎಂಬಾಕ್ಸ್‌ನ ಮುಖ್ಯ ಆಲೋಚನೆ ಲಿನಕ್ಸ್ ಇಲ್ಲದೆ ಲಿನಕ್ಸ್ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಬಳಸುವುದು. ಅಂದರೆ, ಯೋಜನೆಯ ಮುಂದಿನ ಅಭಿವೃದ್ಧಿಗೆ ಕೊಡುಗೆ ನೀಡುವ ಮುಖ್ಯ ಸಕಾರಾತ್ಮಕ ಅಂಶವೆಂದರೆ ಯೋಜನೆಯನ್ನು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಬಳಕೆದಾರರು ಬಳಸುತ್ತಾರೆ ಎಂಬ ಅರಿವು ಮತ್ತು ಇದು ಅವರ ಕೆಲವು ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಬೇಕು.
ಆ ಸಮಯದಲ್ಲಿ, ಎಂಬಾಕ್ಸ್ ಈಗಾಗಲೇ ವಿದ್ಯಾರ್ಥಿ ಯೋಜನೆಯ ವ್ಯಾಪ್ತಿಯನ್ನು ಮೀರಿ ಹೋಗಿತ್ತು. ವಿದ್ಯಾರ್ಥಿ ಮಾದರಿಯ ಪ್ರಕಾರ ಯೋಜನೆಯ ಅಭಿವೃದ್ಧಿಯಲ್ಲಿ ಮುಖ್ಯ ಸೀಮಿತಗೊಳಿಸುವ ಅಂಶವೆಂದರೆ ಭಾಗವಹಿಸುವವರ ಪ್ರೇರಣೆ. ವಿದ್ಯಾರ್ಥಿಗಳು ಅಧ್ಯಯನ ಮಾಡುವಾಗ ಭಾಗವಹಿಸುತ್ತಾರೆ, ಮತ್ತು ಅವರು ಪದವಿ ಪಡೆದಾಗ, ವಿಭಿನ್ನ ಪ್ರೇರಣೆ ಇರಬೇಕು. ಪ್ರೇರಣೆ ಕಾಣಿಸದಿದ್ದರೆ, ವಿದ್ಯಾರ್ಥಿಯು ಯೋಜನೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತಾನೆ. ವಿದ್ಯಾರ್ಥಿಗಳು ಮೊದಲು ತರಬೇತಿ ಪಡೆಯಬೇಕೆಂದು ನಾವು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡರೆ, ಅವರು ಪದವೀಧರರಾಗುವ ಹೊತ್ತಿಗೆ ಅವರು ಉತ್ತಮ ತಜ್ಞರಾಗುತ್ತಾರೆ ಎಂದು ತಿರುಗುತ್ತದೆ, ಆದರೆ ಯೋಜನೆಗೆ ಅವರ ಕೊಡುಗೆ, ಅನನುಭವಿ ಕಾರಣ, ತುಂಬಾ ದೊಡ್ಡದಲ್ಲ.
ಸಾಮಾನ್ಯವಾಗಿ, ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು ರಚಿಸುವ ಬಗ್ಗೆ ಮಾತನಾಡಲು ನಮಗೆ ಅನುಮತಿಸುವ ಮುಖ್ಯ ಅಂಶಕ್ಕೆ ನಾವು ಸರಾಗವಾಗಿ ಹೋಗುತ್ತೇವೆ - ಅದರ ಬಳಕೆದಾರರ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುವ ಉತ್ಪನ್ನವನ್ನು ರಚಿಸುವುದು. ನಾನು ಮೇಲೆ ವಿವರಿಸಿದಂತೆ, ಓಪನ್ ಸೋರ್ಸ್ ಯೋಜನೆಯ ಮುಖ್ಯ ಆಸ್ತಿ ಅದರ ಸಮುದಾಯವಾಗಿದೆ. ಇದಲ್ಲದೆ, ಸಮುದಾಯದ ಸದಸ್ಯರು ಪ್ರಾಥಮಿಕವಾಗಿ ಬಳಕೆದಾರರು. ಆದರೆ ಬಳಸಲು ಏನೂ ಇಲ್ಲದಿರುವಾಗ ಅವು ಎಲ್ಲಿಂದ ಬರುತ್ತವೆ? ಆದ್ದರಿಂದ, ತೆರೆದ ಮೂಲವಲ್ಲದ ಯೋಜನೆಯಂತೆಯೇ, ನೀವು MVP (ಕನಿಷ್ಠ ಕಾರ್ಯಸಾಧ್ಯ ಉತ್ಪನ್ನ) ರಚಿಸುವುದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಬೇಕು ಮತ್ತು ಅದು ಬಳಕೆದಾರರಿಗೆ ಆಸಕ್ತಿಯಿದ್ದರೆ, ಯೋಜನೆಯ ಸುತ್ತಲೂ ಸಮುದಾಯವು ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನೀವು ಸಮುದಾಯ PR ಮೂಲಕ ಸಮುದಾಯವನ್ನು ರಚಿಸುವಲ್ಲಿ ತೊಡಗಿಸಿಕೊಂಡಿದ್ದರೆ, ಪ್ರಪಂಚದ ಎಲ್ಲಾ ಭಾಷೆಗಳಲ್ಲಿ ವಿಕಿ ಬರೆಯುವುದು ಅಥವಾ ಗಿಥಬ್‌ನಲ್ಲಿ ಸರಿಯಾದ ಜಿಟ್ ವರ್ಕ್‌ಫ್ಲೋ ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಯೋಜನೆಯ ಆರಂಭಿಕ ಹಂತಗಳಲ್ಲಿ ಇದು ಅಸಂಭವವಾಗಿದೆ. ಸಹಜವಾಗಿ, ಸೂಕ್ತವಾದ ಹಂತಗಳಲ್ಲಿ ಇವುಗಳು ಮುಖ್ಯವಲ್ಲ, ಆದರೆ ಅಗತ್ಯ ವಸ್ತುಗಳೂ ಆಗಿರುತ್ತವೆ.
ಕೊನೆಯಲ್ಲಿ ನಾನು ಸೂಚಿಸಲು ಬಯಸುತ್ತೇನೆ , ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಓಪನ್ ಸೋರ್ಸ್ ಪ್ರಾಜೆಕ್ಟ್‌ನಿಂದ ಬಳಕೆದಾರರ ನಿರೀಕ್ಷೆಗಳನ್ನು ಪ್ರತಿಬಿಂಬಿಸುತ್ತದೆ:
ನಾನು ಈ OS ಗೆ ಬದಲಾಯಿಸುವ ಬಗ್ಗೆ ಗಂಭೀರವಾಗಿ ಯೋಚಿಸುತ್ತಿದ್ದೇನೆ (ಕನಿಷ್ಠ ಪ್ರಯತ್ನಿಸಿ. ಅವರು ಅದನ್ನು ಸಕ್ರಿಯವಾಗಿ ಅನುಸರಿಸುತ್ತಿದ್ದಾರೆ ಮತ್ತು ಉತ್ತಮ ಕೆಲಸಗಳನ್ನು ಮಾಡುತ್ತಿದ್ದಾರೆ).
ಪಿ.ಎಸ್. ಆನ್ ನಾವು ಮೂರು ವರದಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಒಂದು ತೆರೆದ ಮೂಲ ಮತ್ತು ಎರಡು ಎಂಬೆಡೆಡ್ ಬಗ್ಗೆ (ಮತ್ತು ಒಂದು ಪ್ರಾಯೋಗಿಕ). ಸ್ಟ್ಯಾಂಡ್ನಲ್ಲಿ ನಾವು ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮೈಕ್ರೋಕಂಟ್ರೋಲರ್ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಮಾಸ್ಟರ್ ವರ್ಗವನ್ನು ನಡೆಸುತ್ತೇವೆ . ಎಂದಿನಂತೆ, ನಾವು ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ತರುತ್ತೇವೆ ಮತ್ತು ಅದನ್ನು ಪ್ರೋಗ್ರಾಂ ಮಾಡಲು ನಿಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡುತ್ತೇವೆ. ಅನ್ವೇಷಣೆ ಮತ್ತು ಇತರ ಚಟುವಟಿಕೆಗಳು ಸಹ ಇರುತ್ತದೆ. ಹಬ್ಬಕ್ಕೆ ಬನ್ನಿ ನಮ್ಮ ಸ್ಟ್ಯಾಂಡ್, ಖುಷಿಯಾಗುತ್ತೆ.
ಮೂಲ: www.habr.com