Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Último
Último (20)
Leveraging Open Source
- 1. Getting Into OpenSource Everything you wanted to know about open source that nobody told you Jeff Genender CTO, Savoir Technologies jgenender at savoirtech.com jgenender at apache.org
- 2. My Style - I ain’t a bullet reader
- 6. This preso is my opinion and others’ may differ Disclaimer: This presentation is based on Jeff’s opinions and experience with open source. Others may or may not agree with what has to be said here. If one disagrees, then they can...
- 7. This preso is my opinion and others’ may differ
- 8. Jeff Genender and OpenSource Apache CXF JSR 316 - Java EE 6
- 9. OpenSource - Why its cool - Do I need to tell you why?
- 10. Do you care?
- 11. Is it because its Free? Free as in Beer?
- 12. What’s the best advantage of OpenSource?
- 13. What’s the best advantage of OpenSource? •Is it Lower Cost?
- 14. What’s the best advantage of OpenSource? •Is it Lower Cost? •Is it easier to customize?
- 15. What’s the best advantage of OpenSource? •Is it Lower Cost? •Is it easier to customize? •Better security?
- 16. What’s the best advantage of OpenSource? •Is it Lower Cost? •Is it easier to customize? •Better security? •Something else?
- 18. Diving Into Open Source - How?
- 21. Pick your Project - Does it Exist?
- 22. Don’t Reinvent The Wheel
- 23. You Decided To Reinvent The Wheel
- 24. You Decided To Reinvent The Wheel
- 25. You Decided To Reinvent The Wheel
- 26. You Decided To Reinvent The Wheel
- 27. Community - The Most Important Piece
- 28. Community - The Most Important Piece X
- 29. Community - The Most Important Piece
- 30. Community Types
- 31. Community Types
- 32. Community Types
- 33. Community Types
- 36. Interacting on the Projects
- 37. Play Nice - Don’t be poisonous
- 38. Parkinson's Law of Triviality (The Bike Shed)
- 39. Parkinson's Law of Triviality (The Bike Shed) AVOID THE BIKESHED!!!
- 40. Interaction and the tools
- 41. Tools for Interacting Remotely Server Side Tools Client Side Tools • Source Control • IRC • Mail Lists • Skype - Keep usage low • Wiki • Forum • Ticket System (Issues) • Continuous Integration
- 42. Source Control
- 43. Source Control
- 44. Source Viewers
- 45. Mail Lists dev@ commits@ private@ users@
- 46. Wiki - Where to go to to RTFM
- 47. Forums
- 48. Ticket System
- 51. Follow the rules
- 52. Your goals for contributing to OpenSource
- 53. Your goals for contributing to OpenSource Learn the tools
- 54. Your goals for contributing to OpenSource Learn the tools Learn the code base and intimately know it
- 55. Your goals for contributing to OpenSource Learn the tools Learn the code base and intimately know it Monitor the mail lists
- 56. Your goals for contributing to OpenSource Learn the tools Learn the code base and intimately know it Monitor the mail lists Find a small itch to scratch on a project • Fix a bug • Offer to contribute some functionality
- 57. Your goals for contributing to OpenSource Learn the tools Learn the code base and intimately know it Monitor the mail lists Find a small itch to scratch on a project • Fix a bug • Offer to contribute some functionality Learn to submit good patches and involve yourself
- 58. Your goals for contributing to OpenSource Learn the tools Learn the code base and intimately know it Monitor the mail lists Find a small itch to scratch on a project • Fix a bug • Offer to contribute some functionality Learn to submit good patches and involve yourself Be helpful in the lists and on IRC
- 59. Your goals for contributing to OpenSource Learn the tools Learn the code base and intimately know it Monitor the mail lists Find a small itch to scratch on a project • Fix a bug • Offer to contribute some functionality Learn to submit good patches and involve yourself Be helpful in the lists and on IRC Main Goal ---> Get commit!
- 60. Bringing the Open Source Way To Your Work
- 61. What’s the Open Source Methodology?
- 62. OpenSource Method - Pass the gate keeper first...
- 63. OpenSource Method - Pass the gate keeper first... Are you already using OpenSource technologies?
- 64. OpenSource Method - Pass the gate keeper first... Are you already using OpenSource technologies? Are you already Agile?
- 65. OpenSource Method - Pass the gate keeper first... Are you already using OpenSource technologies? Are you already Agile? Are others willing to play in a more Agile environment (or just you)?
- 66. OpenSource Method - Pass the gate keeper first... Are you already using OpenSource technologies? Are you already Agile? Are others willing to play in a more Agile environment (or just you)? Is your boss cool?
- 67. Mimic It! THAT is the OpenSource Methodology dev@ users@ commits@ (no need for private@)
- 68. Real Life Example #1
- 69. Real Life Example #2
- 70. Now what you have been waiting for...
- 71. Hey Jeff... How can I get paid to write OpenSource?
- 72. How I did it - About me Jeff The Lowly Contractor 2004 jgenender@ apache.org
- 73. And one thing led to another... Websphere CE JSR 316 - Java EE 6 JSR 244 - Java EE 5
- 74. And it kept on leading... Apache CXF JSR 316 - Java EE 6
- 75. Tip #1 - Pick a project that has legs
- 76. Tip #1 - Pick a project that has legs X
- 77. Tip #1 - Pick a project that has legs
- 78. Tip #2 - Get Commit!
- 79. How to get commit
- 80. How to get commit Learn and support how things are done on a project
- 81. How to get commit Learn and support how things are done on a project Learn politics... every project has them
- 82. How to get commit Learn and support how things are done on a project Learn politics... every project has them Be nice
- 83. How to get commit Learn and support how things are done on a project Learn politics... every project has them Be nice Get involved on mail lists and IRC
- 84. How to get commit Learn and support how things are done on a project Learn politics... every project has them Be nice Get involved on mail lists and IRC Submit patches to fix bugs (check the bug tracker list)
- 85. How to get commit Learn and support how things are done on a project Learn politics... every project has them Be nice Get involved on mail lists and IRC Submit patches to fix bugs (check the bug tracker list) Discuss and submit a major component • This one can get you commit very very quickly
- 86. Tip #3 - Do conferences - Speak! Fat ugly guy here (Sweden 2008)
- 87. Tip #4 - Ego sucks
- 88. Tip #5 - Keep at it
- 89. Questions?
- 90. Thank You! jgenender at savoirtech.com jgenender at apache.org
Notas do Editor
- \n
- Talk about the presos are pictures and I speak through things. This isn’t about bullets and I am not a bullet reader.\nI have a few slides with bullets... but for the most part you are encouraged to take notes.\n
- Seriously... the rules of engagement.\n
- I will ask questions and I want answers. I hear about these european countries of silence. Lets get involved.\n
- Opensource carries a very opinionated view of software development due to its agility. So therefore I am.\n\nMake them repeat the text!\n
- Opensource carries a very opinionated view of software development due to its agility. So therefore I am.\n\nMake them repeat the text!\n
- Opensource carries a very opinionated view of software development due to its agility. So therefore I am.\n\nMake them repeat the text!\n
- Tell about yourself - End with - people always ask how I got into open source. This presentations talks a bit about that.\n
- Its the rebellion of the software age. It thumbs its nose at the big vendors like IBM, Microsoft, and Oracle, etc. It gets under their skin. Its disruptive. It kills their business models and forces them to change.\nThis big software houses never thought what open source would do to them... never thought that free software would be taken seriously and that it had no chance with quality.\n
- Ask who cares about OpenSource and why? Get people to speak.\n
- Ask is it because its free. Ask people to raise their hands if they think its free.\nIts free to developers but not to companies. Because it still costs to maintain it and develop with it.\nLicensing costs are only a small part of the equation for cost.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- Computer Economics conducted a survey of visitors to its website regarding the perceived advantages in the use of open source software.\n
- People always ask me how I got into Open Source. There are a couple of routes and I did it through a hybrid of these 2 routes. Route 1 - Necessity - Use an open source project with bugs. Talk about Xcel Energy here. Route 2 - You have a need... you need to scratch that itch.\n
- What do I mean by scratch that itch?\nNeed to build something you need or want to build. Be passionate. Talk about JBoss and how it competes with the big boys.\nTalk about experience with IBM and I was forced to work on things I didn't like\nDon't pick something you hate.\n
- Does it exist? Is someone already doing it? Look at Apache, Codehaus, GitHub, Google Code, Sourceforge, etc and see if there is someone who already has something you can be a part of.\n
- Don’t try to reinvent the wheel unless the project is really crumby or the community stinks. Is the codebase really bad? Is it salvageable? Is it even worth contributing to? I’ll discuss community in a minute, but some communities are terribly poisonous. Why help a dictatorship?\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- You musta had a good reason. Its certainly doable. Talk about Jetty. Talk about the help from investors.\nTalk about how they are on a road to unseat Tomcat. They took advantage of trying to do it better, along with taking advantage of a broken community. Talk about how successful they have been.\nHint at how if Jetty had a more open community, their road to success would have been better.\n
- Ask who saw this movie? Who believes it? The mantra “if you build it”, they will come is not correct.\nThis is the most overlooked part of any project. Most folks believe code over community. Apache believes in community over code and are successful. Explain the more people you have, the more contributors and the better the code gets. Example: Linux.\n
- Ask who saw this movie? Who believes it? The mantra “if you build it”, they will come is not correct.\nThis is the most overlooked part of any project. Most folks believe code over community. Apache believes in community over code and are successful. Explain the more people you have, the more contributors and the better the code gets. Example: Linux.\n
- Ask who saw this movie? Who believes it? The mantra “if you build it”, they will come is not correct.\nThis is the most overlooked part of any project. Most folks believe code over community. Apache believes in community over code and are successful. Explain the more people you have, the more contributors and the better the code gets. Example: Linux.\n
- Ask who saw this movie? Who believes it? The mantra “if you build it”, they will come is not correct.\nThis is the most overlooked part of any project. Most folks believe code over community. Apache believes in community over code and are successful. Explain the more people you have, the more contributors and the better the code gets. Example: Linux.\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- 2 main types. Type 1) The Despot. He makes all the rules. Sometimes can be successful. many times not.\nTalk about Jetty again. Talk about WADI. Then GWT-EXT. 2) Community driven (sometimes called socialist view) where the community makes the decisions\n
- These are the more popular, but there are others like java.net, and kanai.com etc. Talk a little about each of these ... some provide a nice slew of tool suites which we will talk about in a second. Talk about how they are fairly open with respect to how you manage. Some have mail lists, etc, some dont. Oops I missed one! Nah... not really.. my favorite Apache! Talk about the Apache way. Success of most projects and the incubator. Talk about community first.\n
- These are the more popular, but there are others like java.net, and kanai.com etc. Talk a little about each of these ... some provide a nice slew of tool suites which we will talk about in a second. Talk about how they are fairly open with respect to how you manage. Some have mail lists, etc, some dont. Oops I missed one! Nah... not really.. my favorite Apache! Talk about the Apache way. Success of most projects and the incubator. Talk about community first.\n
- These are the more popular, but there are others like java.net, and kanai.com etc. Talk a little about each of these ... some provide a nice slew of tool suites which we will talk about in a second. Talk about how they are fairly open with respect to how you manage. Some have mail lists, etc, some dont. Oops I missed one! Nah... not really.. my favorite Apache! Talk about the Apache way. Success of most projects and the incubator. Talk about community first.\n
- These are the more popular, but there are others like java.net, and kanai.com etc. Talk a little about each of these ... some provide a nice slew of tool suites which we will talk about in a second. Talk about how they are fairly open with respect to how you manage. Some have mail lists, etc, some dont. Oops I missed one! Nah... not really.. my favorite Apache! Talk about the Apache way. Success of most projects and the incubator. Talk about community first.\n
- These are the more popular, but there are others like java.net, and kanai.com etc. Talk a little about each of these ... some provide a nice slew of tool suites which we will talk about in a second. Talk about how they are fairly open with respect to how you manage. Some have mail lists, etc, some dont. Oops I missed one! Nah... not really.. my favorite Apache! Talk about the Apache way. Success of most projects and the incubator. Talk about community first.\n
- Discuss interaction on projects. That a good project will have contributors from all over the world. The need to be able to interact remotely with others in an efficient manner is crucial. We can talk about the tools in a minute, but lets discuss the most important part... (next slide)\n
- Talk about email and forum interaction. Need to be inviting to people. You are going to get all types asking questions and trying to contribute. You will see flame wars. You shouldn’t flame either. Chill out ... walk away for 1 hour before pushing send. Talk about myself being guilty of this. Avoid long drawn out threads and emails. Keep your questions concise and short.\n
- A nuclear reactor is used because it is so vastly expensive and complicated that average people cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminum, asbestos, or galvanized iron, rather than whether the shed is a good idea or not. The committee then moves on to coffee purchasing, a discussion that results in the biggest waste of time and the most acrimony. FROM FreeBSD - "The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."\nContribute because you have something to add or is productive. Don’t respond to something just because you want to show “who is da man!”\n
- A nuclear reactor is used because it is so vastly expensive and complicated that average people cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminum, asbestos, or galvanized iron, rather than whether the shed is a good idea or not. The committee then moves on to coffee purchasing, a discussion that results in the biggest waste of time and the most acrimony. FROM FreeBSD - "The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."\nContribute because you have something to add or is productive. Don’t respond to something just because you want to show “who is da man!”\n
- A nuclear reactor is used because it is so vastly expensive and complicated that average people cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminum, asbestos, or galvanized iron, rather than whether the shed is a good idea or not. The committee then moves on to coffee purchasing, a discussion that results in the biggest waste of time and the most acrimony. FROM FreeBSD - "The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."\nContribute because you have something to add or is productive. Don’t respond to something just because you want to show “who is da man!”\n
- A nuclear reactor is used because it is so vastly expensive and complicated that average people cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminum, asbestos, or galvanized iron, rather than whether the shed is a good idea or not. The committee then moves on to coffee purchasing, a discussion that results in the biggest waste of time and the most acrimony. FROM FreeBSD - "The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."\nContribute because you have something to add or is productive. Don’t respond to something just because you want to show “who is da man!”\n
- A nuclear reactor is used because it is so vastly expensive and complicated that average people cannot understand it, so they assume that those working on it understand it. Even those with strong opinions often withhold them for fear of being shown to be insufficiently informed. On the other hand, everyone understands a bicycle shed (or thinks he or she does), so building one can result in endless discussions because everyone involved wants to add his or her touch and show that they have contributed. While discussing the bikeshed, debate emerges over whether the best choice of roofing is aluminum, asbestos, or galvanized iron, rather than whether the shed is a good idea or not. The committee then moves on to coffee purchasing, a discussion that results in the biggest waste of time and the most acrimony. FROM FreeBSD - "The really, really short answer is that you should not. The somewhat longer answer is that just because you are capable of building a bikeshed does not mean you should stop others from building one just because you do not like the color they plan to paint it. This is a metaphor indicating that you need not argue about every little feature just because you know enough to do so. Some people have commented that the amount of noise generated by a change is inversely proportional to the complexity of the change."\nContribute because you have something to add or is productive. Don’t respond to something just because you want to show “who is da man!”\n
- Talk about that people need to communicate with each other. Telephones just won’t work. Should you even be interacting by voice at all?\n
- Bullet reader now. Discuss the server side tools at a high end. Explain some of the communities may provide some or all of them for you. Explain the different communites may offer robust tools or really crappy versions.\n
- Talk about the different source control and how SVN is now the most prolific...which has majorly replaced CVS (Concurrent Versioning System). Git and mercurial are distributed - explain why that is cool. Git is coming up heavily in popularity and many projects are moving over to it due to its impressive tool suite.\nExplain that these are optimistic source control systems. Then show VSS and why its pessimistic parts are bad for open source.\n
- Talk about the different source control and how SVN is now the most prolific...which has majorly replaced CVS (Concurrent Versioning System). Git and mercurial are distributed - explain why that is cool. Git is coming up heavily in popularity and many projects are moving over to it due to its impressive tool suite.\nExplain that these are optimistic source control systems. Then show VSS and why its pessimistic parts are bad for open source.\n
- Talk about the different source control and how SVN is now the most prolific...which has majorly replaced CVS (Concurrent Versioning System). Git and mercurial are distributed - explain why that is cool. Git is coming up heavily in popularity and many projects are moving over to it due to its impressive tool suite.\nExplain that these are optimistic source control systems. Then show VSS and why its pessimistic parts are bad for open source.\n
- Talk about the different source control and how SVN is now the most prolific...which has majorly replaced CVS (Concurrent Versioning System). Git and mercurial are distributed - explain why that is cool. Git is coming up heavily in popularity and many projects are moving over to it due to its impressive tool suite.\nExplain that these are optimistic source control systems. Then show VSS and why its pessimistic parts are bad for open source.\n
- Talk about the different source control and how SVN is now the most prolific...which has majorly replaced CVS (Concurrent Versioning System). Git and mercurial are distributed - explain why that is cool. Git is coming up heavily in popularity and many projects are moving over to it due to its impressive tool suite.\nExplain that these are optimistic source control systems. Then show VSS and why its pessimistic parts are bad for open source.\n
- Explain the different ones. Some of these are a part of who you sign up with.\nExplain Atlassian and how powerful it is and their open source licensing model. Explain Apache and Codehaus use it.\n
- Discuss the various lists.\nDiscuss the moderation aspect... nothing comes for free and that includes no spam.\nRemind that again its crucial to interact with kindness no matter how much n00b. Thats how you build community.\n
- Ask folks if they know what RTFM means. Wiki is key for documentation. It came as a need as a place to collaborate and have multiple people contribute to documentation. Some wiki’s like Confluence allow you to export the site as documentation - so its a win/win.\nThere are many kinds. The more popular are shown here Confluence, Twiki, MoinMoin, Twiki. Agiain, some project sites include this as part of their offering (GoogleCode, SourceForge, Apache, Codehaus).\n
- Explain a bit about forums. Some projects use em. Some dont. Most apache projects dont. But a few do. Great place for interacting with your user base. Seem to be getting more popular.\n
- Ticket systems are key. Its how to track bugs... and if you have a great project, you will have lots of them. The fewer the bugs the less\n
- Explain why continuous integration is and why its important. Multiple developers... someone can mess up the program and blow the party for everyone else with a bad commit.\nExplain Cruise control, cc.net for dot net and cc.rb for Ruby.\nFew opensource projects provide continuous integration, but Apache does provide it at a project’s request.\n
- Explain about IRC... great interaction with users. Great way to become friends with folks. Great for group discussion. Its loggable (so be careful what you say).\nExplain when Skype would be used (i.e. Too much to go over in irc and you are a committer on a project)\n
- Each project has a set of rules to engage. It also has a set of coding standards. Some are written. Some are not. Follow the style and your patches will be accepted.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- #1 - Many tools are the same across projects. Learn how to use svn/git and be able to effectively submit patches\n#2 - Get to know the code base and you should really understand how it works and the styles used\n#3 - Be sure you are kept up to date on who is working on what and the issues of the day.\n
- Ask how many people are using some form of open source at work? How many aren’t and plan to?\nHow many won’t let open source in?\nHow many use the open source development methodology at your work? How many wish they did?\n
- Its agile. Its real agile. But why adopt it? The primary reason is you can get extremely high quality software doing things the open source way. Look at what is out there... Apache Httpd... Linux... etc. How are they able to produce such high quality with so many developers world wide? Since it works... bring it on home.\n
- Q1 - Yes? Its easier to bring in. No? Better start there.\nQ2 - Do you use an agile method already like SCRUM or XP, or are you a CMM shop? Better get past this next.\nQ3 - Better find major support or you will have your work cut out for you\nQ4 - A stick in the mud is gonna be hard to get past\n
- Q1 - Yes? Its easier to bring in. No? Better start there.\nQ2 - Do you use an agile method already like SCRUM or XP, or are you a CMM shop? Better get past this next.\nQ3 - Better find major support or you will have your work cut out for you\nQ4 - A stick in the mud is gonna be hard to get past\n
- Q1 - Yes? Its easier to bring in. No? Better start there.\nQ2 - Do you use an agile method already like SCRUM or XP, or are you a CMM shop? Better get past this next.\nQ3 - Better find major support or you will have your work cut out for you\nQ4 - A stick in the mud is gonna be hard to get past\n
- Q1 - Yes? Its easier to bring in. No? Better start there.\nQ2 - Do you use an agile method already like SCRUM or XP, or are you a CMM shop? Better get past this next.\nQ3 - Better find major support or you will have your work cut out for you\nQ4 - A stick in the mud is gonna be hard to get past\n
- Look at your favorite open source projects that produce a fantastic product and follow what they do right.\nUse Atlassian because you can integrate it and your boss can get stats. Make mail lists and let people subscribe to them so they don’t get development spam. Use the mail lists for discussion. Conference call with skype (tell them its a set up for work at home). Use IRC... its really awesome. You can create a channel on many servers and secure them with passwords.\n
- Talk about Xcel energy and IBM third generation. Explain how the stars were aligned correctly for open source.\nTrading unit - financial - no money for licensing but for labor. Explain the setup...\nLinux, JBoss, SVN, etc etc. Explain how we were able to obtain unfettered access to the net through a strict firewall.\nExplain how after our project the CTO started an OS group in XCel.\n
- Talk about the setup - JIRA, Confluence, Bamboo, svn, irc chat.\nTalk about nervousness of the remote thing, and it was an experiment. Delivered a service based solution on time and was done by a team scattered in Canada, US, and Mexico. It wasn’t an outsource project.\nStandups done by Skype.\n
- Ask who came hear to listen about open source? Ask who came here to learn how to get PAID for working in open source?\nOk... I have keep most of you bored... right?\n
- Nothing like being a cube monkey... working on boring drab code that never sees the light of day or a death march project.\n
- \n
- \n
- \n
- Don’t reinvent the wheel unless you are ready to work your butt off. Coming up with something that nobody had done before is tough. Your goal is to get noticed.\nChoose a popular project that is a sign of the times. Be sure it has string community. Apache!\nRight now it seems to be cloud computing. Read up on who the VCs are interested in.\n
- Don’t reinvent the wheel unless you are ready to work your butt off. Coming up with something that nobody had done before is tough. Your goal is to get noticed.\nChoose a popular project that is a sign of the times. Be sure it has string community. Apache!\nRight now it seems to be cloud computing. Read up on who the VCs are interested in.\n
- Ask if folks know what a committer is.\nThe committership is the holy grail. Its the keys that gets to being noticed. Just being a contributor isn’t enough.\nCompanies take notice of committers as the experts and instantly become candidates for a job that uses the project.\n\n
- \n
- \n
- \n
- \n
- \n
- \n
- Speaking does several things for you. You get to play with the other “cool dudes” in your industry. They take notice of you. Yes... we then netowrk together. We drink the mother’s milk together. We give each other jobs. But companies take notice too.\nTell them how many gigs I get offered.\n
- Talk about ego and bonding with everyone. Nobody is too good for anyone else.\nTalk about Marc Fleury\nYou aren’t better than anyone else.\n
- You are never too old to do it.\n
- \n
- \n