TITLE OF PAPER: Flour and water make bread URL OF PRESENTATION: _URL_of_powerpoint_presentation_ PRESENTED BY: David Ascher REPRESENTING: _name_of_the_company_they_represent_ CONFERENCE: PyCON 2004 DATE: 20040326 LOCATION: _venue_and_room_in_venue_ -------------------------------------------------------------------------- REAL-TIME NOTES / ANNOTATIONS OF THE PAPER: {If you've contributed, add your name, e-mail & URL at the bottom} Water is pure, open, transparent and has a source water = open source flour = business (industrial/packaging/selling) yeast/butter/etc. = work/engineering/etc. bread = money ActiveState making bread since '97 acquired by Sophos - antivirus/spam corp dev tools for open source da eating bread since '90 Chief Technologist ActiveState (small part of Sophos) Author, Learning Python Director, PSF Sophos, a proprietary software company, acquired ActiveState, an open-source based company, and integrated the open-source-based software into their strategy. Assumptions People need jobs, even open source programmers Jobs should be fun Businesses provide jobs (good at it) Business is about providing value for customers (and shareholders, but let's not worry about that) Beliefs Open source software can be high-quality /technology/ Some businesses provide good value /products/ Working with open source can be fun Open source technologies and businesses can be good for each other ActiveState has built open-source-based products over the last seven years. Languages, toolkits, libraries, components, packages, apps... Open Source 101 blah blah blah (i.e. some arguments for business types) So there's massive value in open source software. Business 101 Businesses compete based on core competencies Writing software products is expensive risky (unpredictable/hard) complicated Open source can reduce risk (in exciting and scary ways): Want to rely on trend of software commoditization. There is pressure not to write software you don't have to. Expenses are much easier to justify than risks. What motivates OSS developers Independence you get to do what you want people may tell you what to do, but you don't have to because you can't get fired. Pride in what you do A forum for technical people to shine Geniuses can implement something really really cool Money / jobs Feedback short feedback loop contrast w/ feedback as a scientist Success by OSS metrics Peer recognition Followers/contributors Stuff being used Analogy to film business Huge Hollywood vs ferociously darwinistic independent filmmakers What do OSS developers fear Becoming a gear instead of a gearhead Technical superiority being trumped by politics marketing business rationales Being coopted Not having fun Being bored What business folks fear (Picture illustrating that you don't want to get distracted) Anything that threatens "the plan" Risk Schedule (most software projects are late) Quality (most software projects have bugs) Legal Lack of control What motivates business people Getting better software faster cheaper Building good/fair partnerships more important to have somebody you can rely on confidence building is very important Doing cool/interesting things Doing things well Claim Businesses can get great value out of open source but often don't. Open source projects/programmers can get great value out of business, but often don't. Build or buy/get? Third party SW (OSS or proprietary) Bugs (mistaken belief that internal sw superior to external) People are less threatened by their own bugs than by other's bugs. License carries restrictions Software liabilities (e.g. patents, copyright violations) The supplier is unreliable unresponsive Internal software Resourcing Can I do that? Do I need to hire? Cost/schedule control? Can I afford it (time/money)? Long-term commitment Can/Will I maintain it? Better to share that responsibility with someone else. How do I justify selling software when I don't want to buy sw. talking about components not trying to justify Advice to business types If you not used to it start small Pick a low risk, high reward technology e.g. scripting language for your app Identify motivation for specific tech. Reduce technology risk/schedule constraints Achieve standards compliance (e.g. libxml) Deliver customizability Prepare a backup plan if things don't work suing the supplier won't solve anything Identify impacted personnel early Marketing, legal, managers, etc. are affected too. Evaluate candidate technologies Health project at least 2 leaders reasonable community Demonstrated strong software engineering - Procedures for reducing risk and increasing the quality of a release Release management Test suites Bug fixing approach Friendly to corporate interest Ownership is clear License is appropriate and clear Other corporate users exist Understand approach to releases, plan accordingly Open source projects tend to release more often It's not necessary to upgrade every time Consider establishing contact especially if (lots of projects get used w/o contacts) Part of "visible" project (i.e. product release) Expect to need help in the future Custom work needed Very different environment Consider contributing back It's part of the "rules" of the game It's the right thing to do Provide input, but remember who's driving Respect the other Making OSS business friendly Provide clarity in: Purpose (what does your stuff does) Direction (where you are planning on taking the stuff) Ownership (who owns the code) Example wrt Python's ownership Licensing (what are the rights granted the user) Example wrt Swish (full text indexer) Licensing options (whether you'll consider a different license) Example MySQL Choose licenses carefully GPL - a very strong door-slam -- no matter how good your tech is, you will not drive somone else's business plan MIT, BSD, Apache - most friendly Take your stuff seriously Software Engineering Release management, documentation, test suites, bug tracking, etc. is all very important Naming Example: Piddle drawing program (not so good) Example: Twisted is okay (some people don't like it) Example: Tcl (tickle) not so good Feel free to let people know if you are available for consulting/contracting/relicensing/etc Respect the other So... Take the time to understand the other Don't be rigid if you truly want useful partnership Communicate Look for common goals Make bread, not war. -------------------------------------------------------------------------- REFERENCES: {as documents / sites are referenced add them below} Swish: http://www.swish-e.org/ -------------------------------------------------------------------------- QUOTES: "Make bread, not war" -------------------------------------------------------------------------- CONTRIBUTORS: {add your name, e-mail address and URL below} Ted Leung, twl@osafoundation.org, http://www.sauria.com/blog Abhay Saxena, ark3@email.com -------------------------------------------------------------------------- E-MAIL BOUNCEBACK: {add your e-mail address separated by commas } -------------------------------------------------------------------------- NOTES ON / KEY TO THIS TEMPLATE: A headline (like a field in a database) will be CAPITALISED This differentiates from the text that follows A variable that you can change will be surrounded by _underscores_ Spaces in variables are also replaced with under_scores This allows people to select the whole variable with a simple double-click A tool-tip is lower case and surrounded by {curly brackets / parentheses} These supply helpful contextual information. -------------------------------------------------------------------------- Copyright shared between all the participants unless otherwise stated...