Getting started with open source, and quick start guide on developing software in collaboration. Anoop Thomas Mathew This book is for sale at http://leanpub.com/opensourcebook This version was published on 2014-05-14 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License Tweet This Book! Please help Anoop Thomas Mathew by spreading the word about this book on Twitter! The suggested tweet for this book is: I just bought Code Explorers Guide to the Open Source Jungle by @atmb4u The suggested hashtag for this book is #openlearnability. Find out what other people are saying about the book by clicking on this link to search for this hashtag on Twitter: https://twitter.com/search?q=#openlearnability Contents Preface i Chapter Description i Contents ii About this book iv 1 In the Beginning 1 1.1 Long Story Short 1 1.2 Advantages of Open Source Software 4 1.3 What is worth Open Sourcing 5 1.4 Getting Started with Open Source 6 2 Knowing by Using 8 2.1 First Interaction 8 2.2 Area of Interest 8 2.3 Different Types of Open Source Software 9 2.4 Anatomy of an Open Source Project 11 3 First Aid Toolkit 13 3.1 Tools in the Toolkit 13 3.2 First glance on Development Process 16 3.3 Frequently used Terminology 17 CONTENTS 4 Collaboration is Communication 19 4.1 Channels of Communication 19 4.2 You are what you write 21 5 Forms of Contribution 26 5.1 Documentation 27 5.2 Bug Reports 27 5.3 Code Review 29 5.4 Feature Requests 29 5.5 Development 29 5.6 Release and Maintenance 30 5.7 Testing 31 5.8 Tutorials, ScreenCasts and Code Snippets 31 5.9 Translations 32 5.10 Design and Artwork 32 6 Running the Show 33 6.1 Ideation 33 6.2 Packaging and Tool-Chains 34 6.3 Managing Community 34 6.4 Version Control 35 6.5 Documentation 36 6.6 Goals and Milestones 36 6.7 Testing; without, you fail. 37 6.8 Quality Assurance 39 6.9 Knowledge Management 39 6.10 Stepping Down 40 6.11 Tips for Creating good open source Software 40 6.12 Version Control and the git Workflow 43 CONTENTS 7 Paying Bills 45 7.1 Business Models 46 7.2 Entrepreneurship and Open Source 46 7.3 Keeping business along with development 47 8 Time Management 49 8.1 Keeping Yourself Motivated 49 8.2 Get a Partner 50 8.3 Not too less, Not too more 50 8.4 Goal Oriented Time Management 50 9 Licenses FAQ 52 9.1 Available License Types 53 9.2 What Kind Of license Should I Choose? 54 9.3 Jurisdiction 59 10 Your Fortune Cookie 68 CONTENTS i Preface Oh! Please dont ask me to read a book, and that too, a book on open source! - I do understand the feeling thats running through your head right now. Please bear with me, Ill try to be interesting, and the maximum extent be away from being boring and being philosophical. This book is a boiled down version of my experiences with open source software for past years, as a user, tester, developer, creator and contributor. Aim is to educate the readers about what all can be done with open source, and explore the untapped possibilities existing with it. I will trying to be generic while going through this book, without specifying names and projects, since my aim is to emphasis the processes and principles which are commonalities for most of the software engineering projects. Chapter Description Each chapter has been designed to be independent of other chapters, and conveys a single idea throughout the chapter. If you feel that ideas discussed in the chapter is something you already know or not relevant to you at the moment, feel free to skip ahead to the next chapter. CONTENTS ii Contents 1. About this book The motivation behind this book and why you should read this book. 2. In the Beginning Serves as a beginners guide to getting started with open source. 3. Knowing by Using Discusses about using the open source soft- ware. How to tackle usual hurdles. 4. First Aid Toolkit Tools and Concepts to be familiar to begin with the collaboration with the community. 5. Collaboration is Communication Teaches you ways of communication in an open source world, and the common netiquette to follow. 6. Forms of Contribution Discusses different forms of contribution, fo- cuses more on the non-conventional jobs in the open source projects. 7. Running the Show How can each of us run an open source project effectively, without getting into trouble. 8. Magic with Time Effective time management tips for open source developers CONTENTS iii 9. Licenses FAQ Open Source licensing options and its signifi- cance. 10. Your Fortune Cookie Relevance of contribution, and the social effects of open community. About this book Checking each update on facebook, twitter and other social sharing applications, there was very little time to be aware of the software development process happening; or at least, the exposure has been minimal. Used to be very curious about things; how does a car work, what does a gear do, why do things work the way they do, and not otherwise. A lot of questions. I had the same questions with the computers Im work- ing on now. But some how, I just couldnt find enough time to get into the zone. To learn more on how software works. How the pieces of code, gets shape and form, handles terabytes of data, data changes shape and becomes all these images, and transforms itself to videos and web pages! I was wonder struck! Wanted to know more about it, but the coziness by the mainstream operating systems and all the abstractions! I want to learn about the magic that happens. Im curious. Welcome to the world of curious people. Welcome to the world of collaboration. Welcome to open source. .. Open Source provides a shortcut to learning deep about technologies buried within the software we use everyday. It lets you do open heart surgery on a About this book v .. software. Im not here to tell you the difference between open source and Free Software. Imnot here for the philosophical preaching. Im not here to evangelize the war of open source projects on properitory software. Im here to guide you in learning the internal workings of epic software and enable you to create and help creating elegant software projects, built by people across the world, which will touch billions of lives and change the course of history. About the Author Anoop Thomas Mathew is the Director of R&D, Pro- foundis Inc., and leads the engineering efforts on products like Vibe and iTestifyIt. He is a Technology Evangelist, Designer at Heart, Public Speaker, Python & JavaScript Hacker. Loves Music, Books and Drawing. He has spoken at conferences like Fifth Elephant 2012, FOSSMeet 2011, PyCon 2012, FOSSMeet 2013, DevCon 2013, PyCon 2013 to name a few. More info: infiniteloop.in http://profoundis.com/ https://vibeapp.co/ http://itestifyit.com/ http://infiniteloop.in/ 1 In the Beginning The beginnings are always troublesome, if you know what I mean. Things wont work in your way. Particularly, when it comes to logical machines, there is only one way to get it right, and another million way to go wrong. This is a very interesting stage, like taming the dragon. Passion and perseverance is the key at this stage. If you dont have both, this would be the right moment, to take a step back and turn around. Adios!
Oh! Wonderful, you chose the adventure, and not to
step back. Believe me. You have taken the first and the most difficult step in the entire journey. Congratulations! This is the book you wanted to read a year before! 1.1 Long Story Short 1.1.1 Long Long Ago Millions of years nature spend in evolution and over the years, the intellectual capabilities have increased by folds. The craftsmanship of creating elegant solutions and meth- ods that had emerged in the animal as well as in the plant In the Beginning 2 kingdom. Humans, being a part of the animal kingdom, too have got a flare of these skills. These skills, keep us on a different platform from that of our ancestor species. Human beings took a leap ahead of other species, and over time, built more of this cognitive skills. It gave us the power to create and control the world around. To understand the world around us, in the scales smaller than the smallest and larger than the largest existed. It enabled us to travel farther and deeper. This made us rulers of the world. This power of imagination and creation started in person. And later on as nomads became settlers. Found ways to communicate. They communicated these inge- nious techniques. This lead to a different level of ideation. They started forming ideas in groups, started creating communities and build social order. 1.1.2 Industrial Revolution People were living like that for a very long time. Without In the turn of 18th century, something magical happened. Till then, wheels turned with humans or animals. Now, machines started shifting the gears and the wheels started turning faster; way too faster than humans could ever do in the past. This also allowed him to spend more time designing and developing rather than working for his basic needs. This gave him the opportunity to create even bigger and complex machines, which evolved faster and in just a mere In the Beginning 3 matter few decades. 1.1.3 Enter Computers Machines reduced human physical effort. Over time it was inevitable to have machines which are capable of handling his cognitive efforts. Machines were built to solve puzzles, manipulate numbers, store information. Computers were born. 1.1.4 Corporations and Ingenuity Humans had the power of collaboration and ideation long time before. All these advancements in the human society gave rise to a systemic yet bizarre construct, which enabled the budding of corporations. Corporations aimed at the principle of more, rather than on better. This strategic difference limited the scope of corporations from trying ingenious ideas and risky ventures. There are a few exceptions for this. Still, this tend to be true for the most of the companies by number. But, the remarkable fact is that, the few of those exception compa- nies rule the industries. Power of expression to people and groups bring-in unimaginable value to the institution. These cabals can yield better solutions for common- niche problems. Rather than work, these kind of interesting puzzles will make people more focused and creative and do wonders.This makes open source the right candidate for the best way to learn, teach and create software. In the Beginning 4 1.2 Advantages of Open Source Software Open Source Software, philosophically creates a demo- cratic system for developing software and maintaining its quality. Developers as well as the users as the co- developers, contribute into the development process, which gives it a lot of advantages when compared to a closed source development framework. The availability of the source code and the right to modify it is very important. The right to redistribute modifications and improve- ments to the code, and to reuse other open source code, permits all the advantages due to the modifia- bility of the software to be shared by large commu- nities. The right to use the software in any way. This, combined with redistribution rights, ensures (if the software is useful enough), a large population of users, which helps in turn to build up a market for support and customization of the software, which can only attract more and more developers to work in the project. There is no one with the power to restrict in a unilateral way how the software is used, even in a retroactive way. There is no single entity on which the future of the software depends. In the Beginning 5 No black boxes are possible. There is always the possibility of forking, or creat- ing an alternative code base if the current one is in some way perceived as wrongly managed. No per-copy fees can be asked for modified versions, and anyone can use the current code base to start new projects. There are fewer conflicting priorities due to market- ing pressures. 1.3 What is worth Open Sourcing There is trick suggested by Jeff Atwood called the rule of three. Quoting him below. There are TWO rules of three in [software] reuse: 1. It is three times as difficult to build reusable components as single use components, and 1. a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library. So, its quite evident that easier something to build, less valuable its going to be in the open source. Also, if its more difficult abstracting the application specific components, the decision to open source has to be rethought. In the Beginning 6 1.4 Getting Started with Open Source To be a developer, you must first be a user. 1.4.1 Using Open Software Its not going to be any different from mainstream software, and it is certain that, its very likely not going to work the way you want like other software and on the flipside, you can make sure that it works the way you want it, provided you are willing to put in considerable effort towards it. Its like a double edged sword. Other than this customization and development opportunity, open source software is as similar as closed source software. 1.4.2 Getting Help For the initial comfort, you can always take refuge in tutorials. Tutorials will give you step by step instructions to get the software working. Slowly, we move into the official documentation and later to the references section as we grow deeper into the intricacies of the software. If you are particular in getting help from another person, you can try mailing lists and IRCs discussed later in this book. In the Beginning 7 1.4.3 Collaboration at Heart Open source projects thrive only on a single reason, Hu- manity. Humans are social beings and are more creative when different ideas are put together. Collaboration cre- ates more usable, diverse and elegant software than one developed without a collaborative ideation or a public code review. Each chapter ahead would walk along you with the concepts you must be knowing while working with open source. 2 Knowing by Using 2.1 First Interaction First baby step is to getting used to an open source op- erating system like Linux or FreeBSD. Its not necessity, but the environment will be more receptive. Ive seen people pick up and grow faster with open source operating systems. Credit goes to the bugs they encounter, and to the successful efforts to fix them and the efforts in vain. This gives an opportunity to learn a lot about the inner workings of operating system as well as nitty gritties of other software components. 2.2 Area of Interest This directly leads us to the next obvious step, to know what is your area of interest. Its a little philosophical and abstract. To think about it, lets take a piece of white paper, and take into account, each and every possible fields like kernel development to documentation, from device drivers to web applications. Consider each of the alternatives, and rate each of them. More over, get used with a few open source tools in that space. Try using the most popular web application framework for your next web project, or check out the Knowing by Using 9 latest video player, or use another popular web browser. You can get a sense of the priorities of the open source software and where it lacks lustre. If you find you can make it shine, there is a vacant seat for you. 2.3 Different Types of Open Source Software System Software It is a difficult task to create software for different devices by the same developer from the same device. This makes a collaborative effort more viable way to develop system software. Also, these software are so unique that one hardware needs only one driver, which should provide all the required APIs. Linux and FreeBSD are two popular open source op- erating system variants, out of many. They do boast of the number of drivers available for devices. If you are interested in embedded or base device interfacing, this is the right place for you to be in. Android on the other hand, is an even popular mobile operating system based on Linux kernel. Libraries Libraries or Plugins or Modules are another class of software which are very viable for open sourcing. If you look at the web market, a lot of Wordpress and Django Knowing by Using 10 extension libraries or modules are available, as reusable components. Examples would be a testimonial system, a commenting system, user accounts and social login etc. Logic is very simple, keeping the reusable parts of the project separate so that others, and of course, yourselves, dont need to repeat the same development cycle over and over. More over, libraries are a smart way to maintain quality of the code, well documented and clearly defined APIs. This is because, multiple projects are using the same code and it is the basic necessity to provide consistent APIs and detailed documentation. Libraries form a very integral part of Linux subsystem, and most of the programs we use will be using a ton of stable libraries. This make it convenient to be maintained by different maintainers, and still, on an entity, feel like a single software. Caution on using Libraries It should be noted, that libraries even being a necessary part in the puzzle, usually de- pendent libraries go missing, unmaintained or change their APIs all together without notice, and can bring in catastophy. Be aware of this weird yet plausible situation, and make your choices wisely. Look for libraries which are actively developed, widely tested and have very good following Knowing by Using 11 Utility Applications The most familiar class of open source applications fall into this space, like Firefox, GIMP or LibreOffice or VLC. These programs helps us to use the devices more effectively. Being a regular user of open source operating system, in course of time introduces you to a ton of utility appli- cations. Development in utility applications is a polarized one, one end of expert and competent developers and the other end with a large number of non-technical users, who provide feedback and feature requests. Frameworks Software often requires a scaffolding or a blueprint to start with, which includes a lot of commonly used functions for a number of different purpose, but will be in a templated manner. Say, for example lets take Django, a web application framework. Every web application needs some kind of a request and response handling sequence, and Django has created a framework to handle such fre- quently used functions. 2.4 Anatomy of an Open Source Project Any open source project is modelled on a few undocu- mented, unwritten principles. These rules are evolving over time from the initial days. Knowing by Using 12 1. Every project would have a central person (Benevo- lent Dictator For Life - BDFL) or a committee to plans and decide on the general course of the software. 2. There will be a source code downloading facility, ei- ther an ftp, http and/or a version controlled interface to do so. 3. There will be a README / INSTALL file to explain the installation of the program from the source, supported platforms etc. 4. Dependencies - open source relies on a network of other open source projects, and are called depen- dencies. You must satisfy the minimum required dependencies to be able to run an open source code. 5. Documentation/Installation - explains the installa- tion process and how to use the software effectively. 3 First Aid Toolkit This chapter discusses most common practices (and tools) for developing open source applications. 3.1 Tools in the Toolkit 3.1.1 Development Tools Integrated Development Environment (IDE) like Eclipse or Netbeans helps you to do the entire development workflow within a single software. Or it can be code editors like vim, emacs or sublimetext which gives you extra functionality over basic text editors. In contrast, IDEs abstracts a lot of processes including the tool chain and build process. For a beginner, this ab- straction raises a number of alarming confusions. Ideally, they should start with basic command line and text editor before moving into fully fledged code editing environ- ments. 3.1.2 Build Tools Often collectively called as the tool chain, these are the build components in the open source development process. These tools may be compilers or interpreters like gcc or First Aid Toolkit 14 python. It can be tools like make, scons or cmake, highly depended on which area you are working on and what are you trying to achieve. General rule of thumb is to first work with a project already in the domain, and follow the tools used, after identifying its advantages and traits. 3.1.3 Version Control As we are into the business of software which will be handled by hundreds and thousands of persons everyday, we need to have a log, as well as a system to keep track of who is changing what. A number of tools are available. Among them, git is the one which stands out. Initiated by Linus Torvalds, creator of Linux kernel, git allows teams to handle code completely decentralized, offline and efficient. github.com While Im writing this book in 2014, github.com, bitbucket.org etc, are few popular amongst other code hosting platforms available for open source programmers, built around version control software such as git and mercurial. 3.1.4 Bug Tracker There are tons of project tracking services, including, but not limited to github, trac, mantis, jira etc. First Aid Toolkit 15 3.1.5 Testing Tools may differ from project to project. But a test runner has to be integrated with the build process to ensure code quality. Passing a test suite before committing into the repository is a great way to prevent breaking code from entering the system on the first place. Also, each and every newfeature, should accompany tests to make sure that they are working as they are intended to be. First Aid Toolkit 16 3.2 First glance on Development Process Open Source Development Process First Aid Toolkit 17 3.2.1 Documentation and Wiki Look for Getting Started Getting Started section usually focuses on the first time users and would be relatively less project specific. Documentation and Wiki pages is usually made avail- able within/along with the project website. There might be downloadable User Manual as well. Wikis usually covers tutorials and general help, while documentation covers in- depth, systematic information about each of the compo- nent. README or INSTALL files also come handy very often. 3.3 Frequently used Terminology Repository The location where code resides. It is usually a version controlled online location. A com- pressed source download method is also found. Fork Creating a new copy of an existing project and working on it as an independent contributor. Forks can be merged back to the original project, provided the owner is interested and willing to accommodate the new changes in the fork. Patch A file which contains the changes made by a specific person. It contains a diff of old version of First Aid Toolkit 18 the code to the new one with changes. Any other developer with the same repository can include this patch to reproduce the same software that was de- signed by the patch creator. Widely used when the user who creates the patch doesnt have write access to the central repository. Commit Process of adding a changeset to a version controlled repository. Commit logs the changes, user info and the time. Commits can be rolled back to re- trieve older versions and navigate through different versions of the same software Branching To create an isolated version of the same code, so that new code experiments could be carried out without affecting the live copy of the code. Any- thing happens on a branch, stays on that branch. Maintainer A person responsible for a particular project or a file in a project. He will be including new changes to it. Pull Request A request made by the contributor to the maintainer to include the changes done by him/her on his/her branch/fork to the primary repos- itory to be added upstream. 4 Collaboration is Communication As we discussed earlier, open source is all about commu- nity, and while collaborating in a community, first and foremost thing to be kept in mind is, everyone elses time is as valuable as yours. So try avoiding confusions as much as possible as it leads to waste of time, of the entire community. 4.1 Channels of Communication In software, collaboration happen mostly online, through IRC/IM chats, mailing list emails, forums, wiki pages and documenta- tion. 4.1.1 IRC IRC or Internet Relay Chat is an Instant Messaging plat- form over which most of the popular open source com- munity have a channel. This is where general discussions Collaboration is Communication 20 as well as weekly meetings are conducted. Its no different from an IM, but people tend to respond a bit delayed. There are popular clients while allows users to connect to corresponding channels on appropriate servers. One of the most common IRC server provider is freenode.net. They have got an browser version of IRC client. 4.1.2 Mailing List A mailing list is a group e-mailing facility, where open source developers and users discuss over development and on bugs or usage support. All the news regarding the new releases as well as new committers, weekly/monthly meeting minutes would be available in the mailing list logs. This is helpful in learning the history of the project for a budding developer. 4.1.3 Documentation Primary source for any information regarding the project. Is a necessary part of any open source project. It will have detailed explanation regarding installation and usage of the software. Extension and also the developer guide for de- velopers who intent to contribute to the project. Usually a reference section is also included with the documentation. 4.1.4 Tutorials and HOWTOs These are blog posts or similar documents, explaining to a newbie, how to get on track with the software. They Collaboration is Communication 21 should be light on language and technology. Steps must be as simple and minimalistic as possible. Screencasts also works great as beginner tutorials. 4.1.5 Website Homepage and front facing page for the project. Needs to express the what, why and how explicitly. All links to the source code, bug tracker, mailing list, documentation, tutorials etc, must be provided in the website. 4.2 You are what you write The mostly used medium is what you write, and that makes it very clear that you should be good enough in written communication to be heard. Some well established written communication netiquette are explained below. Be concise. Get to the point. Many of the members on the lists are hard at work coding for one company or another. Some of those coders take breaks to check these lists to see whats going on and how they can help. They dont have time to read through your life long journey. Be specific. Before you post your problem make sure you have collected the relevant data. If you have a video problem make sure you know the video card you are using, the driver you have installed, the version of the kernel you are using, and which Collaboration is Communication 22 release of the distribution you use. The more relevant information you give the more likely you will get help. No Flame wars - Which one is better is a very person to person question, and trying to win someone who doesnt agree with your ideaologies are very likely waste of time. Its better to explain project ideologies in a wiki, and avoid unproductive discussions. Be Constructive Man 1: You know what, I use Software X. Its much faster and stable than other distri- butions Man 2: Do you have this Q feature? This Software M got the that. You must check it out Man 1: No ways. Im sure Software X is the best. It has got W feature. Man 2: M has got R, S and T features, do you have any idea? (and a lot of further waste of time.) Do NOT top post. What is top posting? Top posting is replying to an e-mail where your reply sits neatly at the top of the reply email. Instead, either reply at the bottom of the e-mail or in line. The main reason for this is so people can followthe thread of conversation that has taken place. Even though this may sound trivial it is taken very seriously in Linux and open source mailing lists. You will be ignored if you top post constantly. Collaboration is Communication 23 Do not insult peoples grammar. Yes, there are gram- mar police all over the place. But the one thing you must remember is that many of these lists are populated by people who use English as a second language. So mocking someone who may wind up saving your skivvies some day is not the best way to make friends. Do not post off topic. This is another issue that resides just under top posting for most annoying to avid mailing list denizens. Keep your posts on topic. Of course there will be the occasional off topic post you will need to get out. For those instances make sure you start the subject with OT: Do not hijack threads. If a thread spawns a new topic for you, post that new topic in your own thread. Never steal someone elses thread from them. Emoticons do not sweep away an insult. You can not reply, But didnt you see my ;-) indicating I was jk? OMG! WTF? You see where this leads? Some developers, when faced with fixing, or adding a feature to an open source project are under the mistaken impression that the first step before any fixing takes place, or before adding a new feature takes place is to make the code easier for them to work on. Easier for them usually is a combination of renaming methods, fields, properties, locals; Refactoring of methods, classes; Gratuitous split of code in different files, or merg- ing of code into a single file; Reorganization by alphabetical Collaboration is Communication 24 order, or functional order, or grouping functions closer to each other, or having helper methods first, or helper methods last. Changing indentation, aligning variables, or parameters or dozen other smaller changes. This is not how you contribute to an open source project. When you contribute fixes or new features to an open source project you should use the existing coding style, the existing coding patterns and stick by the active main- tainers choice for his code organization. The maintainer is in for the long-haul, and has been working on this code for longer than you have. Chances are, he will keep doing this even after you have long moved into your next project. Sending a maintainer a patch, or a pull request that con- sists of your fix mixed with a dozen renames, refactoring changes, variable renames, method renames, file splitting, layout changing code is not really a contribution, it is home work. The maintainer now has to look at your mess of a patch and extract the actual improvement, wasting precious time that could have gone to something else. This sometimes negates the effort of your contribution. If you really have an urge to refactor the code, first of all, discuss the changes with the maintainer with the rationale for the changes. If the maintainer agrees with the changes, make sure that you keep your refactoring and changes independent from code fixes, it makes reviewing the code a lot simpler. Collaboration is Communication 25 The alternative, to keep your fork, is usually a guaran- tee that your effort will be wasted, and wont help other users. People have tried to do this. It is attempted every year, by hunders of developers who in tbe back of their minds are thinking I can do better and I wont make the same mistakes. So respect the original coding style, and if you want to make refactoring changes, discuss this with the maintainer. 5 Forms of Contribution First shot code contribu- tors are very few. An often held misconception is open source is all about developers. The fact remains, more than 80% of the community comprises of technical writers, reviewers, bug reporters, maintainers and translators. Being a developer is not the only thing you can do for open source. A code coughing machine doesnt make a good developer either. It needs understanding of the human-computer interaction mechanism, stickiness to the process, persistence, and above all a well formed social outlook. Other tasks such as translation or testing would be insightful for a new developer to get accustomed with the community as well as the code base. Contrary to the normal belief, a ton of ways are avail- able contributing to open source other than development. Most common job descriptions available with open source projects are listed below. Documentation Forms of Contribution 27 Bug Reports Code Review Feature Requests Development Release and Maintenance Testing Tutorials, ScreenCasts and Code Snippets Translations Design and Artwork 5.1 Documentation Documentation is the process of letting users and devel- opers know what does your code do, and how to use it in the right way. Usually done by the author himself, but there are cases where English is not authors first language, and needs someone else to work with him to make the documentation effective. Rephrasing documentation to be more simpler and accessible is another interesting task within documentation. Documentation should ideally contain an Installation section, Getting Started, detailed functionality of each and every utilities available and extensive API reference guide. 5.2 Bug Reports Anything non-trivial program has bugs - anonymous developer. Forms of Contribution 28 A great way to contribute to the community. Many bugs are platform specific and users on that platform can only Not at all difficult as you may think! Go to the project page, search for bugs/issues/tickets Usually its a bugzilla bug tracker or github issues or any other ticket man- aging system. Create an account, and find create a bug report button. Go ahead and create a bug report, u will need a title for the bug and a short description of what you expe- rienced. Additional information like a screenshot of the bug, environment de- tails, severity of the bug and whomyou think would be the right guy to look at it are optional details you can add along with a bug report. Forms of Contribution 29 5.3 Code Review A time consuming, yet interesting way to learn and enter into the development of the software is to review others contribution. Its one among the easiest ways to get more context about the repository, and getting into the developer circle in the project. 5.4 Feature Requests Avid users of the concerned software knows the Achilles Heel of it better than a seasoned developer. They would know which new feature would make more sense and what bugs to fixed in priority. These people care raise feature requests and ask core developers to create those features. Many a time, these kind of feature requests and discus- sions over them, decide the course of the project, leading it to a much better position and acquiring larger userbase. 5.5 Development Developing in a real world open source project contributes to a very tiny portion of the time. Time is mostly spend on designing and discussing other plausible solutions for the problem or a more efficient way to implement the existing solution. Once the solution is confirmed, its programmed in the corresponding programming language, tests are written Forms of Contribution 30 and using the tool chain, compiled/interpreted to create the desired output. Always make sure that the code committed to the repository are bug free and end-to-end tested. There are not many things more embarrassing for a programmer than having an explicit bug on the public code committed. It is well advised to include the documentation for the newly added code together with the same commit. To document line by line is an excellent practice to ensure that other developers will be able to decypher what each lines mean. 5.6 Release and Maintenance Packaging the software for the easy consumption and upgradable should be of top priority. Users working with archaic versions of software bundled with the deployment will have to compile the code from the source to use the latest version. Every package will have a maintainer, who keeps track of new features included, version and packages to different platforms the software has to be distributed. Most of the packages in the open source has the potential to be dis- tributed across all platforms including UNIX distributions, like Linux, FreeBSD and Mac OS as well as Windows environments. Forms of Contribution 31 5.7 Testing The Linux kernel development works in a very peculiar way. You can write some code, make sure that all tests passes on your machine. You can contribute a patch. And if the code is valuable, it will be pushed upstream. Now, youd think what if that code is not working on platforms other than that of yours. Exactly! Linux kernel has the most number of platform supported and it is achieved by multiple people from multiple bizarre platforms test report bugs and get it fixed. Considering these facts, we must understand the significance of writing tests, and running tests in the development process. Benchmarking the project in comparison with other available projects in the similar field would provide valu- able insights regarding where the project stand compared to its peers. 5.8 Tutorials, ScreenCasts and Code Snippets If you are good at technical writing, communication, this task is for you. Writing blog posts, HOW TOs, enriching documentation, creating Getting Started video tutorials and sample code snippets fall into this category. To grow the community, the most important task is to making the getting started part the easiest. Forms of Contribution 32 5.9 Translations Translating open source projects to native languages had been one of the primary task any developer can easily get started with. This has got two significant advantages; contribution process is relatively easy, and can instantly connect with the softwares local community. 5.10 Design and Artwork At the end, it should look great. It had been the case of open source software till the mid 2000s, very numb looks. Even now, artistic skills of programmers are in question. This creates a separate group of people who can think in an artistic sense and design websites, posters, logos, and documents for the open source projects. A presentable open source project is always preferred to a dull looking project; even if the software is designed elegantly. 6 Running the Show Starting to play around with a community is interesting, but more than a interesting game as soon as the project gets popular. It needs careful nurturing at each stage to keep the project alive and on schedule. Some ideas on how an entire open source project lifecycle works is discussed in this stage. 6.1 Ideation Everything starts with ideation stage. To get an idea is easy, but to validate whether it is interesting to others as well is a very difficult process. This is not a necessary thing in open source, while something being in the open source domain, is supposedly used by a lot of people and others contribute in the general development workflow discussed in the previous chapter. Ross Gardler, former Manager of OSS Watch, believes that the scope of an open source project can be formalised by looking at a number of key attributes that characterise an open development community, namely: a deep level of user engagement: if you dont have users then there is no point having a project. Running the Show 34 collaboration: a means of working within a diverse group of people, something that the Internet has obviously made easier. agility: once work begins and there is a serious engagement with users, ideas and plans may need to change. sustainability: having the capacity to keep develop- ing an application solution over the necessary period of time. tools: wikis, bug and version-trackers and email lists to support the development of the community and keep track of intellectual property rights, if relevant. 6.2 Packaging and Tool-Chains Development activity on open source projects is constant and concurrent among many developers. Sometimes the changes made by one developer interfere with those made by another developer. Often the version control practices used in the open source community resolve these conflicts, but sometimes they do not. Frequent automated builds and tests of the software being developed are powerful tools that help catch logical conflicts early. 6.3 Managing Community Software developers spend a large part of their time com- municating with each other. Clear and effective technical Running the Show 35 communications are needed to keep the team in sync and to allow individuals with key knowledge to apply that knowledge where it is needed. One tenet of the open source community is that tech- nical communications should take place in public forums. Mailing lists are the backbone of open source communica- tions. Beyond that, open source projects need support for precisely communicating technical details and for group decision-making. There can be weekly/monthly/yearly meetup (online/of- fline) for the developers in order to discuss the progress and also, future plans. Every task should be assigned to someone in the community, so that everyone is responsible for some part or the other. 6.4 Version Control Every software development project needs version control. This is very important to keep track of the history as well as maintaining integrity while multiple person are working on the same code from different geographical locations at the same time. Open source projects need strong and flexible support for many concurrent developers working on overlapping sets of files. Running the Show 36 6.5 Documentation Document Every Line It might sound absurd, but in a few weeks, even the code written by you will look like gibberish. Let others know whats in your head. Open source projects also need standard templates for design docu- ments, technical documentation, and end user documenta- tion. A well-organized project should facilitate distributing these documents. But, the nature of open source projects demands that these files are globally accessible, and that administrative overhead be minimized and responsibility be spread out over the members of the development com- munity. A central wiki could serve as an ideal candidate for collating all such documentation, tutorials, and guides. 6.6 Goals and Milestones Every project needs explicit goals, resources, and a sched- ule. The open source community has addressed these issues in a uniquely flexible way. Shared to do lists keep track of tasks that need to be done. Personal to do lists keep developers on track. Milestone lists set flexible deadlines for individual features based on feedback from users and developers. Running the Show 37 6.7 Testing; without, you fail. Its like doing the first flight with a 1000 souls on board. The chances of going under is very high, and without any previous consideration, you are stepping into disaster. Enter Testing. Testing is an integral part of the development, and ideally, open source projects, which is being developed from different locations all over the globe, should have a code coverage of 100%. Meaning, each line of code should be accompanied by a test. Wait! what is testing by the way? Lets consider a case here. Person A and Person B is working on the same project. Person A is working on feature 1 and person B on feature 2. Person A finished feature 1 and moves on to feature 3. In the mean time, Person B finishes feature 2, and tries to include his changes. Problem here is Person Bs feature 2 is break- ing Person As feature 1. What can we do about it? Before Person B includes his new set of changes, he runs the test suite, which contains testing cases for the features Person A has added. Now that there exists tests, its easier for Person B to identify Running the Show 38 that feature 2 is breaking the code, he can make changes so that feature 1 is also intact. Even if all testing practices are prominent and popular in the open source world, Id recommend unit test or module testing as a mandatory. This ensures that each module is working perfectly. One thing to be remembered while attempting to write a test is to make sure you are focusing on the things that are likely to break, and are depended on external factors, like a global variable, or a user input. A good test would consist of all possible cases that will completely cover all the features. Write test for the feature you add It is ideal, recommended, and in some com- munities mandatory for each of the feature addition to be accompanied with comprehen- sive test cases. Software engineering practices are key to any large development project. This site provides a home to conduct open source or collaborative software projects integrated with a set of hosted development tools to facilitate project teams adopting the best practices that have proven them- selves in the open source community. Running the Show 39 6.8 Quality Assurance Open source software products have achieved a remarkable degree of quality. This is something that the closed source development world has found to be one of the most difficult and costly aspects of software development. Developers are self-selected by their interest and knowl- edge of the application domain. Requirements are tacitly understood by developers who are themselves users of the software. Technical communications (including bug reports) are conducted in public. The public nature of open source helps developers take pride in their successes and think twice before releasing faulty code. Furthermore, debugging is much more effective when split among many people who have diverse knowledge and accessbility. For example, one person might have a non-UNIX machine. He may not know anything about programming or development, but he can make sure that the software which he uses is working exactly as intended and report bugs, if any. 6.9 Knowledge Management Knowledge is the valuable resource that sets experienced developers apart from novice ones. Sharing knowledge effectively has been key to the success of the open source community. Explicitly managing knowledge can help re- duce the learning curve for novices which reduces the bar- Running the Show 40 riers to entry for potential contributors while automatically keeping the load on the experts down to a minimum in terms of training others. 6.10 Stepping Down Over time, either the core members priorities might have changed or better and more competent contributors joins the team, the core members should realize the fact, and step down. This is not an option; this is a necessity. A necessity to avoid making the project an abandonware. 6.11 Tips for Creating good open source Software Eric S. Raymond in his book The Cathedral and the Bazaar points to 19 lessons learned from various software development efforts, each describing attributes associated with good practice in open source software development as follows: 1. Every good work of software starts by scratching a developers personal itch. 2. Good programmers know what to write. Great ones know what to rewrite (and reuse). 3. Plan to throw one [version] away; you will, anyhow. (Copied from Frederick Brooks The Mythical Man Month) Running the Show 41 4. If you have the right attitude, interesting problems will find you. 5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor. 6. Treating your users as co-developers is your least- hassle route to rapid code improvement and effective debugging. 7. Release early. Release often. And listen to your cus- tomers. 8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone. 9. Smart data structures and dumb code works a lot better than the other way around. 10. If you treat your beta-testers as if theyre your most valuable resource, they will respond by becoming your most valuable resource. 11. The next best thing to having good ideas is recogniz- ing good ideas from your users. Sometimes the latter is better. 12. Often, the most striking and innovative solutions come fromrealizing that your concept of the problem was wrong. 13. Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away. (Attributed to Antoine de Saint-Exupry) Running the Show 42 14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. 15. When writing gateway software of any kind, take pains to disturb the data stream as little as possible and never throw away information unless the recip- ient forces you to! 16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend. 17. A security system is only as secure as its secret. Beware of pseudo-secrets. 18. To solve an interesting problem, start by finding a problem that is interesting to you. 19. Provided the development coordinator has a com- munications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one. Running the Show 43 6.12 Version Control and the git Workflow Git Branching Workflow Running the Show 44 As shown in the picture, a branched workflow needs to be devised with a distributed version control software, ensuring a conflict-free software development process, also maintaining the backward compatibility and strictly fol- lowing agile development model. 7 Paying Bills The main issue with open source and free software is that, it sounds like is a cheap and low cost affair. The fact is, its NOT. RedHat Inc., an open source based company is valued at $1.4 billion. This definitely proves that open source software do have business potential. At the end of the day, you need to make sure that all your bills are paid, Even if you are a full time open source contributor, you need to make sure that. There are gov- ernment and university grands, fellowships, donations and other monetary support mechanism for open source soft- ware, building a business around the open source ecosys- tem proves to be the most appealing one to be on the sweet spot, Working on what you love to do Contribute back to the society Make enough money to pay your bills Let us discuss some business models possible together with open sourcing the code which does the magic. Paying Bills 46 7.1 Business Models Open source on itself is NOTa business model. It is a collab- orative software development practice. Provided that, open source do have viable as well as proven business models built around it over time. We can classify them broadly into 4 categories Building products on top of open source Eg: Facebook, Twitter Delivering services for open source Eg: wordpress Selling support for open source Eg: redhat, mysql, mongodb Provide consulting for open source Eg: tons of them 7.2 Entrepreneurship and Open Source There are some striking similarities between entrepreneurs who move ahead and start their own businesses and the Paying Bills 47 ones who initiate open source projects. Both of them senses the need for such a piece of missing jigsaw. Both parties are not in the game just for monetary benefits and enjoys doing what they do. Open source software provides a easily accessible plat- form for the entrepreneurs to head start ahead of the proprietary software. A software entrepreneur must consider the possibility utilizing and contributing to the open source community as a whole. Consider open sourcing internal tools or con- tributing the repositories you use very often. Give enough freedom to the employees to doodle with interesting projects and encourage contributions. Google has did this very effectively by giving 20% of the work time to do what ever they wish to do. It is proven that these company independent hacking will lead to creative products and more exciting business opportunities. 7.3 Keeping business along with development This is a hard task to do, when you are running a company. Your preferences changes time to time in a company, and to keep on developing a particular project needs dedication. There is always a great way to induct new and budding developers and making them maintainers for the project. There are tons of projects unmaintained due to the shift in the company strategy. Those projects would benefit from Paying Bills 48 interested people who can contribute and direct the project to a successful destination. 8 Time Management Goals and Milestones Open Source projects, as like other software projects, require careful planning and well set goals and milestones. 8.1 Keeping Yourself Motivated Motivation comes with an expiry date. This makes it nec- essary for you to keep on inspiring yourselves, by setting weekly goals, and quick sprints. One option is to spend an hour a day on it after work. Progress is slow. But slow but steady is better than nothing. Planning on how you can make small tasks helps find the motivation. Its less overwhelming to create a form with one element than a whole app. Other options are to work on it during your commute (if you take mass transit) or during your lunch break. Time Management 50 8.2 Get a Partner If you can partner up with someone, it makes the project a lot easier and more enjoyable (if you find the right person). See if there is someone at work, or a friend, or even an online contact who might want to work with you on the things youre doing. Partner need not necessarily local, but someone in the online community can act as a partner. Meanwhile do not mistake a partner with a mentor. Its completely different concepts. 8.3 Not too less, Not too more Make sure that the project is not eating away most of your time. Or, its not getting enough attention, as it requires. Just focusing on only one project at a time, escpecially if it is not a paying and primary job, it is a matter of concern. So, the ideal way is to have atleast commit every day. This is a principle which have returned great results, as you can contribute some of your time everyday, but not too much to bite of your key focus. Believe me, one commit a day is not a hard goal to achieve. 8.4 Goal Oriented Time Management Create goals for every week, which keeps you on the clock all the time, and keep it more organized. This is really Time Management 51 interesting if you are working on a long running project. Please dont try to bite it all once; it will not work. Create small, easily achievable milestones, which would inturn motivate you on further progress. John Bytheway Inch by inch, lifes a cinch. Yard by yard, lifes hard. 9 Licenses FAQ Every single line of code written by a pro- grammer is copyrighted by default. Yes! If any one wants to share the code with anyone else, he has to explicitly mention the license agreement. And this gave rise to all the GPL and BSD and other licenses. Licenses FAQ 53 9.1 Available License Types Comparison of popular Software Licenses There is an interesting perspective in haaked.com on dif- ferent types of software licenses. According to it, there are only 4 types software licenses available 1. Proprietary - The code is mine! You cant look at it. You cant reverse engineer it. Mine Mine Mine! 2. GPL - You can do whatever you want with the code, but if you distribute the code or binaries, you must make your changes open via the GPL license. Licenses FAQ 54 3. New BSD - Use at your own risk. Do whatever the hell you want with the code, just keep the license intact, credit me, and never sue me if the software blows your foot off. The MIT license is a notable alternative to the New BSD and is very very similar. 4. Public Domain - Do whatever you want with the code. Period. No need to mention me ever again. You can forget I ever existed. 9.2 What Kind Of license Should I Choose? This section is based on an article by Rowan Wilson, which you can read online at http://oss-watch.ac.uk/resources/licdiff. There are many free and open source software licenses, and while they all broadly attempt to facilitate the same things, they also have some differences. Some of the major differences can be grouped together into categories, and this document acts as an introduction to these categories. Having read this document, you should be able to under- stand which decisions you should take in order to select a license for your code. 9.2.1 Staying Mainstream The Open Source Initiative - a non-profit organisation formed to educate about open source - maintains a list of licenses that they see as being popular and widely used Licenses FAQ 55 or with strong communities. The purpose of the list is to highlight those licenses which are likely to answer the needs of many licenses new to open source. The list also helps to make the task of open source license selection seem manageable; the full list of more than 60 licenses can be daunting, and contains many licenses which are in most ways similar in function to one or more of the popular and widely used listed licenses. Using a license that many others use has some advan- tages. If the terms of the license are challenged, there will be a larger pool of licensees with an interest in funding a response to the challenge. Using one of the popular and widely used licenses also makes it more likely that your licensees will already be familiar with the terms you are offering. Equally though, licensees should not feel locked in to only using a popular and widely used license. Some of the features we discuss below are only present in the wider pool of all OSI-approved licenses. 9.2.2 Permissive And Copyleft All free and open source licenses allow others to make modified versions of your code, and to make these modified versions available to others. The license you choose can make conditions about how this happens - specifically what licenses can be used on these modified versions. These conditions can help keep your code free, but they can also put some people off reusing your code. Such conditions are sometimes called copyleft conditions, in a play on the Licenses FAQ 56 word copyright. Open source licenses that do not seek to control how modified code is licensed are often referred to as per- missive licenses. While the original code covered by a permissive license stays under that permissive license, any modifications to it can be released under any license that the modifier chooses, open source or not. This means that permissively licensed code can form the basis of closed source products. Some argue that this makes permissive licenses more free than copyleft licenses, in that people who modify the code are freer to choose what they do with it. Others argue that the lack of a requirement that modifications be open source means that permissive li- censes are less free. As discussions of ideas of freedom - and particularly the idea of compulsion to be free - are essentially philosophical they fall outside the scope of this document. It is worth noting, however, that there are differing views within the free and open source world about what free in the sense of freedom really means. .. Example As part of her astrophysics research Anne creates a standard for recording a specific kind of complex data object. She also writes code to create and parse files that adhere to the standard. Anne is keen that the standard becomes widely used, as minority standards are far less useful. Therefore she decides that she will Licenses FAQ 57 .. release the code under a permissive license. Anne believes that by allowing creators of both closed and open source projects to use the same code to create and read the data objects, uptake and efficacy of the standard will both be helped along. 9.2.3 Strong And Weak Copyleft Should you choose to include copyleft licensing conditions on reuse of your code, there is a further choice to be made. Copyleft licenses are broadly divided into two strengths: strong and weak. Strong copyleft conditions dictate that when a piece of software contains some of your code, the software as a whole must be distributed under your license, if it is distributed at all. The effect of this will be that the source code to all additions made to the code will be available. Weak copyleft, on the other hand, means that when software contains some of your code, some parts of the software must be distributed under your license, if the software is distributed at all. Other parts may be distributed under other licenses, even though they form part of a work which is - as a whole - a modified version of your code. One effect of this will be that the source code to some additions made by others to your software may not be available as open source. Another effect may be that people may find it easier to productise your code by adding closed Licenses FAQ 58 components and selling licenses to these closed parts. To choose a specific weak copyleft license, you must also decide precisely which parts of your code will retain your license and what kinds of additions can bear a license of the modifiers choosing. This division can happen at one of three levels: Module level weak copyleft licenses dictate that each functional sub-section (module) of code within the software is considered separately. Where a module contains some of your code, it must bear your license. Where it does not, the owner of that code gets to choose their own license for that module. File level weak copyleft licenses dictate that each col- lection of code and data that is distinct according to the computers file system is considered separately. Where a file contains some of your code, it must bear your license. Where it does not, the owner of that code gets to choose their own license. Library interface level weak copyleft licenses are generally used where your code is a software li- brary (a collection of software functionality which is usable by other programs via an agreed interface). Modifications of your library must bear your license, if they are distributed. Programs that use your li- brary, and are perhaps distributed alongside it, need not use your license. Licenses FAQ 59 .. Example Barry writes a piece of C code that examines websites over a network connection and generates image file diagrams of the links between their pages. Barry wants to release his code under a copyleft license because he wants to mandate access to the source code of all modifications of his program that are released. However, Barry also wants a wide variety of projects to be able to use his program - partly because he believes this will encourage the useful modifications and optimisations of his work that he wants to see. Barry decides to package his program as a library and use the library interface level weak copyleft license the GNU LGPLv2.1 on it, as it seems to him that this represents a good balance between encouraging reuse by both closed and open source projects while mandating the release of source of modifications to the parts he is interested in - his own code and the functionality it embodies. 9.3 Jurisdiction A jurisdiction refers to a specific location or territory and its system of law. Where a license specifies a jurisdiction, the licensor and the licensee(s) agree that the terms in the Licenses FAQ 60 license are to be understood in reference to that jurisdic- tions law and that legal action resulting - for example - from breach of the licenses terms will take place in that jurisdiction. While jurisdiction is an important issue, it may be worth noting that traditionally free and open source soft- ware owners do not tend to seek monetary damages from those who infringe their licensing terms, but seek instead to compel the infringer to either abide by the terms or terminate their use of the code in question. For these purposes it is often unnecessary to resort to actually taking an infringer to court, particularly if they have a public profile and reputation to protect. Often simply requesting compliance can be effective, and if that fails, publicising the infringement can help achieve compliance. Not all free and open source software licenses specify a jurisdiction. In fact most are silent on the subject. In these cases any jurisdic- tion can be selected when and if necessary, although it is quite possible that the person you are trying to take to court will either ignore you or dispute your choice of location if it does not suit them. Finally some free and open source software licenses state that the jurisdiction is either up to the licensor or automatically that of the licensor (where they reside or principally do business). .. Example Licenses FAQ 61 .. CrabApple University is keen to write a policy on open source release, as an extremely large endow- ment specifies this as a pre-condition. Lawyers within Crabapple decide that a key piece of this policy must be the anointing of a specific license as the institu- tions preferred option when licensing out software as open source. At the first meeting to discuss which license to choose, it is pointed out that the institu- tional insurance policy does not cover legal action abroad. It is therefore decided that an essential feature of the anointed license must be that it enforces a local jurisdiction for any legal action resulting from the release of software it covers. 9.3.1 Patents Do you or your institution own any software patents? If you do, and you release some code that embodies them under a free or open source software license, then you are very likely to be granting rights to use the relevant patent (in connection with that code) to anyone who chooses to use it - even if the license does not explicitly say so. In many jurisdictions, for example the UK and the US, licensing someone to take a particular action (like copying or adapt- ing your code) can also impliedly license them to take all other steps necessary to take that action. These impliedly licensed steps would almost certainly include use of your Licenses FAQ 62 embodied software patent. It should be noted that people who adapt your code cannot expand its functionality to capture other software patents of yours - you grant rights only to the patents embodied in the code you released, not any subsequent form the code may take. Some free and open source software licenses say nothing on the subject of patent grants - although as noted this may not mean that they grant no patent rights. Some free and open source software licenses explicitly grant patent rights necessary to use, adapt and distribute the software. Your free or open source software license can also in- clude what is sometimes called a patent retaliation clause. These sections of a license essentially say that anyone who brings legal action alleging that the licensed software embodies one of their software patents will lose the license you have granted to copy, use, adapt and distribute the code. Such a clause is intended to dissuade people from bringing this kind of legal action. .. Example Professor Dopaska has created a software-embodied process for predicting civil unrest that his university believes is patentable. The professor is keen to release the software embodiment of this process under the permissive Apache License, v2, as he wishes to see the process used ubiquitously to enhance his aca- demic reputation. Knowledge transfer staff at Profes- Licenses FAQ 63 .. sor Dopaskas institution are not keen on this idea, as they wish to obtain the patent and build a spin-out company around it, and believe that the open source release will undermine the licensing income of this venture. 9.3.2 Enhanced Attribution All free or open source software licenses specify that any- one who distributes or adapts the software must give credit to the original authors of the software somewhere in their distribution. Some free or open source software licenses go further than this, and specify that the credit must take a particular form and appear in specific instances, for example on the softwares user interface every time it is run. This kind of stipulation is sometimes called enhanced attribution or badgeware. .. Example Edward creates a tool for visualising the frequency of occurrences of words in documents in an attractive way. Edward surmises that the tool will probably be used widely, but is not essential enough to most users core business to support a paid licensing model. In truth, what Edward really wants to achieve is Licenses FAQ 64 .. publicity for the promotional consultancy he runs and for which the code was written. Edward decides to release his tool under theCommon Public Attribution License v1 as this mandates the display of a URL, a graphic and an attribution phrase every time the software is run. Edward provides his consultancy sites URL, logo and strapline along with the software so that users will help promote his business when they use and reuse his code. 9.3.3 The Privacy Loophole If someone uses your code to create an online service or an in-house solution, perhaps adapting and improving it, most free and open source software licenses do not specify that the source to the adapted or improved version must be released. Most free and open source software licenses make it a condition of distribution that source code be released. In general neither making services available over a network, nor using the code, nor deploying the code within a single institution is defined as distribution within these licenses. Some within the free and open source software com- munity feel that this phenomenon, sometimes called the ASP (application service provider) loophole or privacy loophole needs to be fixed. Their argument is that fairness dictates that all those who benefit from the code must contribute their work back to the world, even if they are Licenses FAQ 65 not, strictly speaking, distributing the code.To address this issue, some free or open source software licenses make release of the source code a condition not only for dis- tribution but also for internal deployment and/or making services available over a network using the software. These kinds of conditions are therefore particularly suited to code which is likely to be used in-house or as a basis for a networked service. .. Example Fareeda wants to build a business providing an easy way for users to build complex slide show music videos from their photographs on social networking sites. She finds a piece of open source software under the GNU Affero GPL v3 which provides a convenient way to handle the requirement that her site must interface with many external sites. Looking into the license, Fareeda discovers that its terms mandate that - if she modifies the code it covers and uses it as the basis of a service provided over a network as she intends - she must also make the source code to her modifications available to service users. Fareeda must now decide if her business model will be unaffected, aided or undermined by this potential responsibility. Licenses FAQ 66 9.3.4 No Promotion Some free and open source software licenses explicitly forbid the use of the authors names to promote a product or service based upon the authors code. .. Example As part of a publicly-funded project Gerhentz Uni- versity creates code which automatically adapts user interfaces to arbitrary display sizes. The institution is keen that the public funding leads to the maxi- mum public benefit both in open and closed source software, and so wishes to release the code under a permissive open source license. However Gerhentz does not wish to be seen to be endorsing products that contain their code, as they feel that this may poten- tially damage the institutions reputation. Therefore it is decided that the BSD License will provide both the wide reusability and block on promotional use that they seek. This chapter has presented some of the key differences between the various free and open source licenses, in order to help you consider what kind of license you might want to apply to your own code. Examples are provided to flesh out the kind of considerations that might feature in your own selection process. Licenses FAQ 67 You should note, however, that there is not a license for every possible combination of features, and so it may well be necessary to compromise on one or more category of features in order to actually choose a pre-existent license. To achieve this it can be helpful to rate the features you desire in order of importance. There are online portals available for easily understand more about the open source licensing options like tldrle- gal.com or choosealicense.com https://tldrlegal.com/ http://choosealicense.com 10 Your Fortune Cookie What is it, in just a few years, that made the world to change its attitude towards programming? I believe its the power of open source. Over 70% of servers run on open source(Apache or nginx servers), over 50% of Fortune 500 has jQuery in it. Bootstrap (a css framework, originated from Twitter, Inc.) with millions downloads. This proves just one thing. No need to flee earth. We still got goodness in it. The popularity of all the above projects are for a few reasons. They solved a genuine problem everybody had or a solution everyone wanted The solution was elegant enough Community was open enough for suggestions and corrections from time to time Development was not stalled at any point of time Monetary benefits was not on the priority list. Are you interested in contributing to back to the hu- manity as a creative person? These are some simple steps for you. Have an open mind. Be receptive. Your Fortune Cookie 69 Be willing to learn new things, be fond of it. Be tireless and be shameless. Try to find problems in the system rather than fitting in, adjusting and getting things done. Finding solution for those problems in an innovative method. Try mix and match different solutions and implementations for the solutions. No solution is new; its just a different configuration of previously existed solutions. s Happy Contributing!