== notes == * convert tosw in to a series of steps * cover the needs differential between sm/med/lg == submission == Brief Description: It's not a magic formula, but following the open source way is also not rocket science. Short Abstract: Learning what it takes to create and grow an open source project is trapped in the brains of many people. This session is going to open the brain of one person who will channel all the experience he has, all that he has learned in open source communities and working for Red Hat, in to taking the audience through how to start and sustain an open source project. Hands on. Long Abstract: Learning what it takes to create and grow an open source project is trapped in the brains of many people. Many people want to know what makes a project tick, how it actually gets things done. This session is going to open the brain of one person who will channel all the experience he has, all that he has learned in open source communities and working for Red Hat, in to taking the audience through how to start and sustain an open source project. Hands on. If we're going to be in a room together, we might as well get some work done toward what interests you. Message to the reviewers: I'm open to adjusting this for different audience types; either on the fly or as per what you need for your tracks. That is, it could be directed at a CIO who is really ready to take an organization in to open source, or it could be directed at a developer team. Audience: Advanced Beginner Developer Everyone Categories: Application Developer Cloud and Virtualization General ==================================================================== Outline ==================================================================== 1. Introduction and bonafides 2. Agenda 3. TOSW.org as upstream here 4. Considerations for project size 5. Large projects are different because ... 6. Small projects are different because ... 7. Sponsored-by-large-org projects are different because ... 8. Academic-sourced projects are different because ... 9. Gov't projects are different because ... 10. All the steps in tl;dnr 11. 1... ... 26. Steps to sustain ** 1... * Steps to grow ** Reasonable growth by project type ** 1... * Conclusions & questions & discussion * Anyone here we can help? sustain steps 1. Get out of the way & let it thrive 2. Improve your infra - focus on enabling contributions 3. Remember what you learned in Kindergarten - be nice, share 4. Focus on legitimate peripheral participation 5. All discussions and decisions must default to OPEN 6. Use version control for content & code 7. Choose open tools that can be extended 8. Focus on keeping the community healthy 9. Keep governance real and active 10. Deal with poison 11. Ongoing communicator(s) are needed 12. Consensus over voting 14. Release early, release often 16. Use a predictable schedule, stick to it growth steps * Embrace failure 15. Evolve with community 13. Change leadership regularly, democratically-by-merit 17. Be students as well as teacher/mentors 18. Drive down barriers ==================================================================== Slides ==================================================================== == S1 == * Title * Presenter === S1 notes === Discuss presentation topic, introduce myself. == S2 == Agenda * What is theopensourceway.org & how is it related? * How does project size & origin come in to play? * All the steps in tl;dnr * Steps to start a project * Steps to sustain a project * Steps to grow a project * Conclusions * Questions and discussion * Anyone here we can help? URL for preso === S2 notes === On the last item, I'm wondering if some of you here are thinking of starting, already have started, or want to look at how to improve your own open source projects. I'd like to see if we can help you here more than just answer questions. For example, if you discover in this process that you forgot to put a contribution policy on your wiki, we can work here on the language and get it posted before the hour is up. So think on that as we talk. == S3 == TOSW.org as upstream here === S3 notes === * What it is, history ** Built on works from others - so if you like the long version, read Producing OSS by Karl Fogel, and so forth. * In progress, like this talk == S4 == Considerations for project size and origin * Generally, all principles apply the same * But size and origin do have special needs === S4 notes === == S5 == Large projects are different because ... === S5 notes === Starting a project as large from the beginning is a huge challenge. You need budget, meaning approval from someone, or someone is you, justification to the board/shareholders/partners. Often people are drawn to making a large project for the same reason they like the Big Reveal. It's part of the way vendors do things. It helps if you can find ways to modularize the project, so each module (sub-project) can thrive and grow on its own. Cf. Apache, Linux Kernel However, it's possible for one person to start something that is effectively huge, such as their own Linux distro. This is really just a small project (one or a few people) with a large goal and audience potential. == S6 == Small projects are different because ... === S6 notes === Small projects have all the usual advantages of being nimble and able to recover from adversity. The disads include the usual hard to do it much with few people, get attention, etc. In FOSS, however, small has special powers. You can attract people who have skills your project needs because people can see themselves part of something smaller more easily than part of a Big Machine. Projects such as Fedora work extra hard to make sure people know they can participate, how to do it, etc. In those cases, you may help 50 people to get one contributor. For a small project, no science here but just instinct says, it's easier to reach people and get them involved in something that they can hold in their hand. == S7 == Sponsored-by-large-org projects are different because ... === S7 notes === Stigma of the large org. People worry about abuses of power. Quality governance is super-important - people have to see how it's enshrined that the large-org isn't going to abuse power. It's easy to have the marketing machine get involved, which can help boost attention. Be very careful that the initial steps are done - that there really is something there - and that most attention is focused on project creation and sustainability and not in getting more t-shirts out to conferences your big org sponsors. There are times when you need to hold off on fully-open, e.g. oVirt. Getting partners lined up can be part of making something be there. In that case, we used a to-be-open list for planning, so in the end it was all transparent. == S8 == Academic-sourced projects are different because ... === S8 notes === Generally, I think academic-sourced projects are more like small projects, except they have the chance to tap in to a Big Machine that can promote, support, budget, hold conferences, etc. The biggest risk is graduation - more people leave academia than stay. Companies don't deal with that, so they can heal quickly when one or two paid project roles need replacement. So it helps if the project is sponsored by a tenured professor, or that it can transition beyond the academic walls when the contributors graduate/move on. == S9 == Gov't projects are different because ... === S9 notes === Governments around the world are different, so it's hard to generalize. For the US gov't there is the situation where work should be in the public domain (which a FOSS license is not), and they often work with contractors who come from traditional software development backgrounds. So a gov't has to make sure that the call for proposals includes that the resulting software is FOSS, etc. One experience I had was with SELinux, where we worked with the NSA. They needed help in creating a real, sustainable project; getting sources upstreamed to the kernel; growing the ecosystem beyond a few small contractors; and making it possible for vendors to create COTS products. The irony is, gov't offices have to procure solutions usually, so if they want to *use* FOSS, it has to be in a product. They can write FOSS, but have to be aware of security, privacy, and issues that a private org thinks differently about. == S10 == All the steps in tl;dnr format: 1. Initial governance. 2. Contribution policy. 3. External main project mailing list. You may choose to hold-off on a general/user discussion list if it's not appropriate for the project, or until they get too annoying in the main project coordination list and need a list of their own. 4. Source control: Code. Content (could be wiki), includes artwork, audio, and so forth. 5. Issue tracker is a general tool or method for the community to keep track of important issues (projects, problems, tasks) in a central way. 6. Wiki for community, collaborative documentation. 7. Weekly IRC meeting time. 8. Team planet/blog feed. 9. Open roadmap for the project on the wiki. 10. Simple open marketing plan, posted on project wiki, talked about on main mailing list. Conferences to submit talks to. Events to attend People to talk to now that there is something to talk about. Local events (user groups, meetups) to attend or organize. Articles for magazines or websites. Hosting online seminars. 11. Expose interesting and easier tasks. Leave smaller work undone and ask for help on such tasks. Look for ways to encourage peripheral participation. 12. Volunteer mentors wiki page. 13. How to participate and contribute page. 14. Community information page: Communication methods listed (mailing lists, IRC channels, etc.) Events attending. Meetups happening. User group events. 15. Participant and contributor improvements and needs page - wish list and roadmap for how things can/should improve for contributors and participants, over time. === S10 notes === Here is the big list. For these, I'm going to break them out to individual slides so we can focus. For the sustain and growth, I won't do that to us. :) == S11 == 1. Initial governance === S11 notes === == S12 == 2. Contribution policy === S12 notes === If there is copyright works being contributed to a commons, then a minimum contribution policy should be maintained. Some projects also use a contributor license agreement (CLA). == S13 == 3. External main project mailing list. === S13 notes === == S14 == 4. Source control: === S14 notes === == S15 == 5. Issue tracker is a general tool or method for the community to keep track of important issues (projects, problems, tasks) in a central way. === S15 notes === == S16 == 6. Wiki for community, collaborative documentation. === S16 notes === You may want another CMS, but wikis work especially well for collab, community documentation. You get to build on the expectation and experience of people, especially if you use the MediaWiki app that Wikipedia is built on. == S17 == 7. Weekly IRC meeting time. === S17 notes === == S18 == 8. Team planet/blog feed. === S18 notes === == S19 == 9. Open roadmap for the project on the wiki. === S19 notes === The wiki makes it both official and friendly to editing, so you again invite participation. == S20 == 10. Simple open marketing plan, posted on project wiki, talked about on main mailing list. === S20 notes === == S21 == 11. Expose interesting and easier tasks. === S21 notes === == S22 == 12. Volunteer mentors wiki page. === S22 notes === People want to know who they can ask questions of. Many people are more comfortable starting in a private, 1:1 setting rather than conducting all their learning on an open mailing list and IRC. == S23 == 13. How to participate and contribute page. === S23 notes === == S24 == 14. Community information page: === S24 notes === == S25 == 15. Participant and contributor improvements and needs page - wish list and roadmap for how things can/should improve for contributors and participants, over time. === S25 notes === == S26 == Sustain steps, only a tl;dnr slide: 1. Get out of the way & let it thrive. 2. Improve your infra - focus on enabling contributions. 3. Remember what you learned in Kindergarten - be nice, share. 4. Focus on legitimate peripheral participation. 5. All discussions and decisions must default to OPEN. 6. Use version control for content & code. 7. Choose open tools that can be extended. 8. Focus on keeping the community healthy. 9. Keep governance real and active. 10. Deal with poison. 11. Ongoing communicator(s) are needed. 12. Consensus over voting. 13. Release early, release often. 14. Use a predictable schedule, stick to it. === S26 notes === Growth steps, only a tl;dnr slide: 1. Evolve with community 2. Change leadership regularly, democratically-by-merit 3. Be students as well as teacher/mentors 4. Drive down barriers 5. Embrace failure 6. ... and more! == S27 == Let's talk about the risks and rewards of growth ... === S27 notes === == S28 == Conclusions? Questions? Discussion? === S28 notes === == S29 == Anyone here needs some help today? === S29 notes ===