The first thing I notice here is that I misspelled Rahm Emanuel, so I apologize for that for all the Americans and the others. How many people actually know who Rahm Emanuel is here?   So if anyone's going to be offended by me cussing like a sailor up here or some of the things that you may see on these slides may project images that could be considered offensive, you may want to go to another talk. I will give you permission to leave now and I will not harass you. Okay, so we're good. When I first submitted a proposal for this talk, I wanted it to be kind of like a rant on open source in the Ruby community. Things change over time and I think I've rewritten this talk three times now. So what I want to discuss today is pretty much open source in the Ruby world and from two sides of the story as a author or a maintainer of an open source project, what you should and what you should not be doing to make our lives in the Ruby community easier and also from a contributor and a user standpoint things that you should be doing with respect to open source to make the world a better place. So let's start off with a little bit of a statistic there. That's 160 million, I believe Ruby gems is like 162 million now, but it's over 160 million downloads of gems from rubygems.org.  The Ruby open source community is ridiculous in the amount of projects that they push out and it's exponentially growing and because of this growth is I want to try and like get everyone on a common ground here and hopefully set some standards. I'm going to throw some opinions out there. I'm a highly opinionated person and we can agree or we can disagree and at least we're going to have a fun time with this. Let's first start as a maintainer of an open source project. I've got expectations when I want to contribute to your open source project and as an author of an open source project of certain basic things that need to be happening in order to make people's lives easier to contribute to the project. So there's some things that I consider understood which not all projects do, but all projects should do. First of all you should be using Git and this is like a thank you captain obvious moment. If you're not using Git, I know Mercurial is kind of a play toy but you should be using Git and you should be posting your project on GitHub. I know there's Bitbucket, there is unfuddle, there's various other sites, but GitHub has pretty much taken over the community, the social coding aspect of GitHub has made contributions to open source just incredible. They've revolutionized the industry and everyone I think needs to embrace it and I know this is kind of like sucking on the mother teeth of GitHub right now, but just do it. RVM, I've gotten a lot of complaints over the last year about RVM, it's not that hard to use, you should be using RVM in your project, you should be committing your RVM RC. Some people will tell you not to do this, I'm telling you to do this. The last thing that I ever want when forking and cloning your repo is to switch into the directory and having my global gem set polluted with dependencies for a specific gem. So definitely use RVM and commit your RVM RC, you should be using Bundler at this point. It's pretty much bug free now, there's a few issues here and there, but what I want to do when I want to contribute to your project is I want to clone the repo, I want to change into that directory, I want to do gem install Bundler, I want to do a bundle install and then I want to run rake and I want it to all work fine and there's really no excuse for that not to work. If there's specific dependencies of your open source library to databases or other frameworks that should be documented in an obvious fashion in order to ease people's setup of your project. Continuous integration for open source, don't do it. Simply put, given this statement, there's no real point when it comes to CI for your open source project to ever have to do it.  It's pretty simple, there's really no need for CI whatsoever and I don't know why open source projects do it and I kind of want that to stop. When I call documentation imperialism. Documentation is a thing that seems to be lacking in the open source community right now. I think there's a very small number of open source frameworks in the Ruby community that really do a good job of documentation. Rails is one of them, DataMapper is one of them, Plug, Mongo is one of them. What I'd like to say is for documentation imperialism is you should shoot for as many lines of documentation that America has troops overseas, that's a lot. But documentation can come in several different forms. The first thing that you can do as an author for documentation is a well-written readme and especially if you're using GitHub, that readme is showing up on your project homepage and this is the best first point of entry to your project on letting people know how to use it. You can use GitHub Wiki for your documentation, let people contribute to it, that's a really easy way as well. Examples, a lot of people like to go to the root of examples in their projects as long as you make it quite obvious that your documentation is an examples directory, code speaks very loud. That's another form of documentation, API doc, this is a small pet peeve of mine for people who write libraries who don't provide API documentation. It's not that difficult, you know, you're probably in the mode of test, implement your methods there, everything's good, write the documentation to that method right at that point. It is lazy for someone not to provide API documentation on any public method in an open source project. People rely on these things to understand what's going on in your framework. Well written test suite, I can't emphasize enough how important testing is in frameworks and I'm going to cover testing in detail here but testing is also documentation and well written test suite is essential to allowing users of your framework to know what's going on and how to use it. For larger frameworks, probably a website for documentation is needed, you know, like I mentioned Rails and DataMapper before, they have very good websites telling you exactly how to use the framework, code examples are really good and any extra resource that you can provide to your users in order for them to use your framework easier is always a good thing. And the last thing on the documentation front which I think is probably the most important thing that you can do as far as documentation goes is mailing list and why I think mailing lists are important is that mailing lists provide context. If I'm searching for a specific issue on whatever framework I'm using, whatever library I'm using and I go to Google and I search for a specific issue and I can get a mailing list thread then not only do I have documentation on how to solve my problem, I've got context around this and I've got context around the decisions that were made around the implementation of that feature, I've got decisions that were made around why maybe something was not implemented and the conversations that happen on mailing lists are far more important than any static documentation can give you. So if you are writing an open source project, I recommend highly that you have a mailing list. More on the testing front. We've gotten into a big thing lately over the past year or two years of the concept of outside in testing and this happens at the application level and usually with cucumber and for application code, this is a great tool. We've got whatever the language you speak, human readable tests that the business can understand that are easy for potentially testers to write but at the same time for library code, this is kind of a waste of our time and I know there are a lot of big cucumber fans out there but I want to tell everyone please do not use cucumber for testing library code. As a developer, I am your user of library code. I don't want to look through cucumber scenarios and then have to go to your step definitions in order to find out the exact code that I need to write in order to use your library. It's an extra step for me that is unnecessary. It's a layer of abstraction in a test suite that should never, ever have to happen for a user who is a developer and if you are one of those crazy psycho developers who loves to go nuts with your regex, my grep becomes useless when trying to find what your feature is actually testing. I'm going to say there's one exception to this rule and that is RSpec and how many people here have looked at the RSpec features. So we can maybe say that David Sholensky is walking the fine line between genius and insanity with those things but if you look at the RSpec features and I'm not showing any code up here for the main reason because usually my talks are code heavy and image heavy and have audio and I'm going bare bones today. If you go to the RSpec features, he's actually testing that a file gets generated with specific code in it in order for you to see the API and if you look at relishapp.com where all the RSpec documentation is, he's using the features as the documentation and to me that's acceptable but it's really excessive on the testing front from a maintainer's point of view in order to do that so anyways. On the topic of outside in testing continuing, we've all drank Jager at some point and I want to introduce a testing technique that I've used for over a year now on library code which I called the Jager Meister technique and we all know that Jager comes in and then Jager eventually comes out. So we're going to call this an inside out testing technique.  So this is what I want to talk about as far as outside in to inside out testing is that when you're doing outside in testing and we're going to say you should be using RSpec here and nothing else, I don't think there's any compelling reason to use any other test framework for library code other than RSpec. You've written your functional tests in RSpec and you've executed everything from a user standpoint entry points to your API but what outside in testing doesn't give you is control over the implementation of your code.  You can go crazy going outside in and what I like to do is you do outside in to make sure your framework works from a user facing standpoint and then you come back and you unit test using mocks inside out and for any of you who are mock heavy testing people, you know that if you've got a poor class design, poor OO design and you're mocking, it is excruciating to mock. So the idea behind this is that you would write your functional tests first, get everything to work and come back around and use your unit tests to flush out the actual OO design of your classes. Another good side to this is that once you've got all your mocks in place and everything is tested and passing for someone to come in to your framework and contribute some code that could be, you know, shady, dodgy. It's going to be a nightmare for them to implement. So you've got control over your design at a level beyond anything else by mocking and doing functional testing. Like Jägermeister, this approach is painful. You feel like and you are doubling your test coverage. For instance, if any of you are familiar with Mongoette and you've looked at the test suite, there's something like 5,000 specs in that test suite. It could be halved if you did just one or the other, but there's a reason for it in that you want to make sure that you can maintain good design and allow contributors to adhere to that design at the same time without, you know, supplying crazy, 100 line method code. We like to talk about code quality versus time to market in kind of all aspects of software. I think I'm being pretty blunt with this slide on what I think about code quality versus time to market and open source. Time to market and open source should not matter whatsoever. It's not a competition. There's no business driving this behind it. You don't have to worry about losing competitive advantages. There's no money involved here. You shouldn't have to feel the pressure to push something to market faster and sacrifice code quality for it as far as open source goes. The Ruby community when it comes to open source is constantly looking for better frameworks, better ways to do things. Always searching for gems. If you write a better gem a year later than someone else did a year before, it will be used. There's no reason to feel forced to push something out earlier. The gem that gets released first does not become the de facto, and if you can't contribute to it, that's not really a big deal. I mean, obviously first you should try to contribute before writing your own, but there's no reason to feel any pressure, and people are going to constantly pressure you into releasing something as quickly as possible, but it's definitely not necessary. That's pretty much all about that. So with accepting patches into open source, you should provide a single way to contribute to your project in just one way, and that should become the standard of contributing to your project. Rails has a thing of doing patches on Lighthouse. I don't necessarily like it, but at least it's one particular way of doing things. I would say if you're embracing GitHub, you go with pull request, for pull request, accept the pull request in. Pull requests are nice on GitHub because they create their own issues, so you've got a code and you've got an issue associated with it, and you've got the project management aspect of it in GitHub. You can have discussions around them, which is great. Everyone can submit a pull request, and anyone who's looking at the project can have a conversation around that pull request. They can say what they like about it, they can say what they don't like about it. You've got more context, and this also leads back into more documentation, because on GitHub, your pull requests, your issues are there forever, and people can search for it. The other nice thing about doing a pull request system on GitHub is that as a maintainer of a project, your commits are parsed by GitHub, and I don't have to go back to the web UI and say, oh, I closed this issue because of such and such. My commit message is automatically put into the pull request and closes the issue, and we're done. Find a dandy. From a user standpoint, and this is something I think a lot of people don't necessarily think about, when you're including a gem in your application, it is part of your application. Any bug, any performance issue in that gem is a bug and a performance issue in your application. It is an extension of your app. As we are open source, the first thing I advise anyone to do on any open source project before you use it is go look at the source code. This is key.   I think a lot of people take, oh, this gem is used for this all the time, and it's very popular, and we'll just use it and not think about it. That's wrong. You should definitely look at the source code of your applications. That's what open source is for. A prime example of this is, I'm a heavy Rails user, but when it comes to relational databases on Rails frameworks, I use Datamapper, and I don't use ActiveRecord, and that's because Datamapper's code, source code, is far better factored than ActiveRecord says, and I trust it. I see too many shady things in ActiveRecord that I don't trust it. Another thing to look for when you're going to use a gem is, besides looking at the source code, make sure it's got tests. Why would you ever use a gem in your application that wasn't tested itself when you yourself, all of us are testing people, right, we're all Ruby guys, we love testing. So just make sure that the gem has tests, and make sure the code is good. Another thing from a user's perspective, and a maintainer's perspective, sometimes you run into an issue with an open source project, and you've gone through the code base and you don't know the best way to fix something. Maybe it's not quite apparent to you, you're new to the project. The absolute best thing you can do, and this is like a ponies and rainbows situation for an open source author, is if you provide a pull request with a failing test. It's almost like I come in my pants when I see this. Pull request, failing test, yes, I pull it in immediately. If you can't navigate the framework or the test suite that well to provide the failing test, the next best thing you can do is, you know, gist. Give some sort of reproducible steps that the maintainer of the project can, you know, start a new Rails project, new Sinatra project, and easily recreate it, and then they can write their own failing test for it. Failing issues for projects without anything is just kind of unacceptable, and it's a waste of people's time. Sometimes people will say, oh, this just doesn't work. Okay. A little bit of context would be good here. Does please provide at least something, but failing test first will bring joy to all of your OSS maintainers' hearts. Twitter. Twitter has kind of gotten out of hand, in my opinion, and by far is it not first line tech support. If you're a maintainer of a gem or an author of a gem, you should document all the channels that people need to go through in order to maintain support for your gem. This can be mailing lists first. This can be GitHub issues. This could be Pivotal Tracker, you know, some other sort of tracking tool, but Twitter is definitely not it, and I think most of us follow hundreds of people and have hundreds or maybe thousands, maybe tens of thousands, I don't know, and Nicholas has got like a million followers. The tweets are going to get lost. We can't keep up with them, so if you're going to tweet for tech support, expect it not to be answered. It's just not the way to do it. Further on the Twitter front. And this is actually my biggest pet peeve with open source, sorry. I know it creates an image that, you know, all eight arms.  At least maybe once a day, twice a day, maybe once a week, depending on the gem, depending on the framework. I see tweets coming out that go something like blah, blah, blah.    And I want to say, like, people work really hard in their free time to write open source software for you, and to do something like this just degrades the whole thing. The least you can show is a little bit of respect for people who are working on these things in your free time and provide constructive criticism.  I disagree with your API because dot, dot, dot. Or there is an issue with this. And here's a gist to show you an example to potentially fix it.  By all means, if you want to call them out on Twitter and say get fisted by the octokat, by all means do so, I will applaud you for that. The other thing, even though I'm kind of ruthless here and saying that is what I usually do, is kill them with kindness. And for most tweets that I've gotten over the past year or two on this front, I usually respond back saying, I'm so sorry that the framework did not do what you expected it to do. Could you provide me with a gist if you have the time and I will get to that issue as soon as possible and hopefully you will be able to use it again. And usually that works far better than telling them to get fisted because people feel bad at that point and then they provide you with a gist and then they become users at the end. But I'm not saying that you can't tell them to be fisted. And wow, I went through that fast. Okay, so that's my story and I'm sticking to it. Yes. Does anyone have any questions? I went 15 minutes too fast. That's if you pull it in, a pull request with just a failing test. That's if you pull it in through the GitHub UI. So that's fine for your fork to have a failing test on it. In my opinion, that's fine. Use the topic branch and you've got a failing test on your fork. No worries. Your suite may be failing, but mine's still passing. Mine's the one that matters, right? Okay. I can't really think of an example where time to market matters. I mean the first one, the first one's going to be the early adopter. But over time, the better one is always or whatever other options you have, they're going to eventually take over. And I see this with Ruby more than any other language that I've worked in in the community is that it seems like every day Rubyists are, I want to know what the next hot thing is. I want to know what new gem was released. I want to use it immediately. Is it better than what I'm already using? And I think that's like a daily thing for people. We're constantly looking at the blogs. We're constantly looking at our GitHub streams. And if something better comes out a year later after we've been using something else, it's going to be adopted. I don't necessarily think, I mean, if you want early adoption, then time to market maybe matters. But eventually, if it's not a superior framework, it's going to be, you know, it's going to be faded out. Closing deal. I mean, so there's a business aspect tied to it, yeah, then that's a different story. What I'm referring to is like pure open source, no business tied to it whatsoever. Yeah. Let's get away from this slide. I was told live coding is like dangerous. Okay. So you've just seen that I've gone into the directory and I've got my, oh, sorry. Can we see this? Okay. Yeah. So it's a basic RVMRC. We say whenever I enter the directory, if that gem set's not already created, just automatically create it. And then in this case, I'm using Ruby 192 and the gem set name is Mongoid. Check that in. If someone doesn't have 192 installed, they will tell them and it's, you know, RVM install 192.  There should be like only two or three gems in my global gem set. So if I want to start deleting projects out of my directory, I don't want like an excessive amount of gems like sitting in my global gem set for things to have to be scanned through. We've got cash, we've got specifications, then we've got all the gems sitting in three different directories. That's not very optimal the way that gems work, but I like things to be fast. I've gotten numerous amounts of emails over the past two years of people telling me to not check in my RVMRC. They're worried about, usually, I think they're not using RVM properly. And for a while, I was like, okay, I'm going to be the nice guy and be like, I won't check in my RVMRC and then I got tired of like going to new machines and then having to create a new RVMRC every time.  In my perfect world, we're all using Bundler and you're pointing directly at the master branch and telling it what commit you want or pointing at a tag. The one thing that I am guilty of is horrible versioning. And I love to change public APIs and patch releases and, you know, so I don't think you should be listening to me on this subject. But in the ideal world, you know, I don't know, there's, we're all using stuff that's not even 1.0 in production apps. So what does 1.0 mean anymore? What does any version number mean to us anymore? I think it's most of the time in our production apps that we use at my current employer, we point at the repos themselves. And if we do a bundle update and something breaks from one of the repos, then we point a specific commit on that repo. But we want the latest and greatest of everything all the time. It doesn't seem like the version numbers in Ruby open source in particular really mean that much. Maybe with the exception of Rails, they're pretty strict on the way that they version things, but every other project is, it seems like a free-for-all. I could be using something in production for two years that's at 0.5. But it works fine. That I'm not really sure about. I think that given, given the way that we treat open source now, especially with respect to GitHub, I think versions are going to fade out. I think they're going to be a thing of the past. And I think maybe tagging, tagging a branch or a specific point in time in your code base will become the new thing. And you may tag it with a name, something instead of a number, something that's more usable to people. Like, oh, what's 1.36 do for me? That doesn't do much. But oh, we just added so-and-so feature here is much more meaningful to me as a developer. So I mean, maybe I'd like to see pointing at specific tags instead of releasing versions at all. I'd miss that one. So he said everyone is using test unit and too complex. Oh, wow. So do we want to tweet this one here? So DHH is a douchebag for saying that. Tweets. Get your phones out. I don't understand at this point in time why anyone, I mean, I understand why Rails, I think I understand why Rails is still using test unit because you've got a massive framework, this framework that's been there before RSpec existed.  But I mean, let's leave by example. Okay. Can I shrink this a little bit? Can we still read it? Is that readable?  In order to do this in test unit, I've got to write 100 character method names. I don't, it's just the organization of it is so much better when you throw in filtering and focus from RSpec. It's such a more powerful framework, for example, and we're sitting on Mongoide right now for things like this. I can do in my setup, if you've got a certain number of databases set up on your local machine, and if they are set up or they're not set up, I'm going to give you warning messages on what you need to do to set them up or not, but I'm not going to fail your test suite because of it. I'm just going to filter them out. So I can do a filter run excluding in RSpec, and then I can say, oh, well, if any of these things are not configured, we're just going to skip them. And then when I go to my tests, you can see here, I do a config slaves on that one that says, oh, well, if the slaves aren't configured, I'm just going to skip this and print that message out. It comes back to the contributing factor in making people's lives painless. Someone who wants to contribute a feature to your open source project that may have nothing to do with slave databases, in my case here, doesn't need to have slave databases running. So we just filter it out if they're not running. That would be, but if I'm hoping in the context of it that if someone's contributing and they know that they're going to affect a slave database right in this fact that they should be running them. I don't think it's that much magic. I mean, for example, and I'll show you this and how we make it a current. So the first thing you're going to get here is because I don't have databases running slave, oh, let's see live coding. There we go, okay. So you can see the because the slave databases are running, the first thing I do is print out a warning message telling you exactly what to do. And that kind of covers my filtering aspect there. I mean, if you don't do something like that, then it can be kind of confusing if you broke anything, but I would say a good pattern is if you're filtering something out and something doesn't adhere to that filter, then you need to be doing something like this. Okay, so we're trying to get an internet connection. Fun. Any other questions? Well, I'm of the opinion that CI, it's not just open source. Open source generally, your core contribution team is not that many people, usually five, six people, maybe 10 tops depending on how big your project is. And I think on any development team, that small CI is actually unnecessary. The only time I've actually found CI necessary was when you have humongous development teams, which shouldn't be happening in any of the Ruby community. This is kind of like a Java.net thing where you've got guys in India, you've got guys in the States, guys in Europe.  And I feel like CI is more of a finger pointing app than actually providing any real value. This is also CI in its current incarnation and that it's not really continuous integration. It's continuous build, continuous run the specs. It's not integrating with anything. True CI, I think, is worthwhile. We've built something and we've deployed it somewhere in order for our users to continue to use it and be on the most recent versions of the software. But I think most people use CI as a build tool and in Ruby it's not building anything, it's just running specs. So I don't really see it deployment. All right.


Namaskar. I'm Professor Devade Purkayastha from the Indian Institute of Technology, Bombay. Welcome to my course, Business Fundamental for Entrepreneurs Part 1, Internal Operations. As part of the course, I'm very pleased to invite Mr. Kalpith Virwal to share a case study about how he founded Accord Boost when he was still a student at IIT Bombay. As background, Kalpith is an alumnus of IIT Bombay and he shot to fame in 2017 when he was probably the first person to achieve complete full marks in the prestigious GE entrance exam, which is an entrance exam to get into IIT Bombay or any of the IITs. He went to complete his computer science undergrad and then he founded Accord Boost while still in the campus and now he's growing his startup. So with this, it's my pleasure to hand over to Kalpith. Welcome to today's lecture. Today we are going to discuss Business Fundamental for Entrepreneurs. I have a company called Accord Boost, Technology is Private Limited and I'm going to tell you how I learned business and I use that knowledge in building my own business. I will also tell you how you can learn those techniques yourselves. So a little bit about me, my name is Kalpith Virwal. I was born in Udaipur and that's where my company, my business operates from. I'm 24 years old. I have a bachelor's in computer science from IIT Bombay and I have some more achievements academically which you can read about NTSC and all indirect one which I got in the GE exam. But more importantly, we are going to discuss about how my business functions and how I started it. So this was just a hobby project which started out as a Facebook page and a blog. Right after my exams were over, I started mentoring students about different kinds of exams and how you can study about them. So I had a Facebook page, I had a Quora page where I had some popularity because of my J results and I gained some instant followers there and then but it was a small number of followers. From there, I grew it just as a passion project, just as a hobby just because I was 17 or 18 years old at that time and I had holidays, I had nothing else to do so I just started writing a bit about how I prepared for my exams. So slowly this evolved into a YouTube channel and then into a website and then we launched our own courses, our own app, iOS as well as Android and then we built an entire platform for students of class 9th till college stage. So we have online courses for all kinds of varieties. We have courses for J students who are trying to get into engineering colleges. We have courses for medical aspirants. We have courses for students who are in classes 9th and 10th and are preparing for different kinds of exams or Olympiads or they just want to get an early start at their entrance exam preparations. We also have courses for students who are in colleges who couldn't get into great colleges and they want to upskill themselves. So we have a complete stack of solutions right from your class 9th till the time you get yourself a good job or a career. So some numbers, we have around 10 lakh plus students across our apps, website, followers, subscribers, all of those things and we have around 10,000 users who have paid us something and this is all with zero advertising spend. All of our marketing is done completely organically. I will talk a bit more about it later on in the lecture. So the first question which arises in our mind when we talk about business fundamentals is that why should we learn business? Why should we even think of learning about a business? Because a lot of us think that business is 100% practical and that it is just a business. A lot of people have this delusion that business studies is not actually a studies. They just think that physics, chemistry, mathematics, biology these things are actual studies and business is more of a practical thing and I do agree with that premise because 80-90% of business is practical but there is a certain section of business which is not completely practical which involves some bit of theory as well. You need to know a bit about finance, you need to know a bit about marketing, you need to know a bit about how to build your product. These are all small, small skills that you need for building a business. So the first thing which I would like to say is that business is basically maths. So there is a formula which I have listed. You can see it here. I have listed this formula. This is all you need to know when it comes to business. So what is this formula? This formula is that traffic which is the number of people who visit your website or who come into your store or who visit your shop, whatever it is multiplied by the conversion rate. That is how many of those visitors can you convert into paid users? Converted by the price of your product, the lifetime value of price. So it could be a subscription product. So let's say you are charging rupees 500 per month or you are charging $100 per month. So if someone stays for 10 months, someone keeps using your service for 10 months, so we count all their revenue. So this is like the complete pricing of your product over a lifetime for an average user, multiplied by the margin. So what is the margin? The margin is basically what percentage of your revenue. So these first three things are your revenue. This is how much money you are making. Now you will also have some expenses inevitably. You will have to pay your employees. You will have to pay people who outsource your things to. You will have to pay for all the services that you use. You will use a lot of product inventory as well. So you will have to pay for all of those things. You will have some kind of depreciation. So all of that is your expenses. So margin is basically the percentage of your revenue, which is left over as your profit, which is in your hand after everything. So you multiply that and this will give you how much profit you are making because in the end, business is about profit. You don't have to make profit on day one, but at some point you have to make profit. So this is the equation and this is all you need to know about running a business. Now there's a lot of study which can go into all of these individually, but basically this is it. So this is the math which I'm talking about in the first point. So business skills is about increasing all four of these things. You want more traffic on your website. So let's say someone has 1000 visitors on their website per month and then there's someone who has 10,000 visitors to their website per month and both of them are in the same business. It's obvious that the second business will have probably 10 times more revenue than the first one because surely because they have more traffic, they have more people visiting their shop. Then if you can convert more, then you will sell more. If you can sell a pricier product, nobody wants to sell a cheap product. Everybody wants to sell expensive products. Everyone wants to sell an iPhone. They don't want to sell some random Chinese company or some cheap phone. They want to sell an expensive luxury product. That's what every business should strive for in theory. And you want to have high margins. You don't want to run a business which has like 1% or 2% profit. For example, the airline industry has an average profit of I think 2%. If you look at the global average, which is abysmally small, right? You want to learn how to build a high margin business, which is usually a tech business, okay? Internet-enabled businesses, online businesses. These are all using technology, right? So these are some ways in which you can boost your margin. So you have to increase all four of these things and that is what business studies is all about. You need to read, analyze, observe and implement, okay? You have to keep on reading analytics. You have to keep on reading books. You have to keep on reading what your customers are saying. You have to observe how people are using your products, what your competitors are doing. You have to analyze what is happening with the traffic. How many people are visiting? What are they doing after visiting? Why are they not buying? You have to observe all of these things and you have to implement strategies in order to succeed, okay? Now, another thing which you must understand is that there is no such thing as, you know, so a lot of people have this thought that they will build a business of, let's say, Rs.5 crore a year, 10 crore a year, whatever the number is and then they will be satisfied with it, okay? Then, okay? Now I don't need to do more, right? They have this kind of a thinking. But this is false. This does not happen in business because in business, you cannot afford to stagnate because there is no such thing as stagnation because the moment you decide to stagnate, you will actually start dipping. You will not stay at the same level. So you have to keep on growing. Even if you want to maintain your business at the level, you will have to work on it. You will have to keep on going. Even if you want to stay wherever you are because of one reason is inflation and because of competitors as well, okay? So you have to keep on learning and improving your business skillset. What are the business skills that you need? So the first skill you need is ideation, okay? You need to be able to think of good ideas and you need to be able to implement those ideas as well. Second is building your product, okay? So an idea is as good as nothing, right? Because the one who makes money, the one who builds a business, the one who gains all kind of popularity and all the benefits of running a business is the one who has actually built the business. It's not the guy who has thought of the business because anyone can think of things, right? What takes effort is building those things.  Then you have to do marketing and sales, okay? This is the lifeblood of any business. If no one knows of your product, your product will simply not sell. You will not make money. If you don't sell, you don't do sales. Then what's the business, okay? Because business is all about selling things. So if you don't sell things, you don't have a business, right? So that is like the lifeblood of a business. Then you have to learn how to leverage others, okay? So you cannot build a business on your own. A lot of people have this misunderstanding in their mind that they can run a business on their own, okay? This is the worst mistake that you can make. Actually you are just becoming a glorified employee. And it's even worse than being an employee because in employment, you don't have responsibilities. You just have to do your work. That's the responsibility you have. You can go home at 9 to 5 and that's it. You get paid.  You are taking the worst side of the business world risk and all the stress that comes with it and all the responsibilities.  So you are taking the worst part of both employment and business. So you have to learn how to leverage other people. You have to learn how to outsource everything you are doing. In the beginning stages, it is okay. You can do everything on your own. But later on, you have to hire people. You have to leverage money as well, okay? So some businesses require a lot of money to grow and you cannot grow or you cannot even start without having money. So you have to leverage investors. Now these investors can be even banks if they give you a loan or it can be someone who is investing in your company in an equity transaction. Then we have tools, okay? So we have a lot of AI tools, software tools which have essentially taken up the role of a lot of people. So in earlier times, we used to have a lot of, you know, people doing very menial tasks like accounting or social media management. Now these things can be automated using tools. So you have to learn how to leverage those as well. And probably the most important skill of all is the last one, which is discipline, determination and risk management. Because for starting a business, you need to have determination and you need to have a healthy appetite of risk, okay? I'm not asking you to go broke trying to run a business. You have to analyze how much risk you can take. Not everyone has the same risk appetite. A lot of people don't have stability in their life, in which case you should reconsider what kind of a business you want to build.  So you have to understand your risk level and you have to calibrate your business model according to that. You have to be determined and most importantly, you have to be disciplined because in every business, there are going to be some very menial tasks which require a lot of effort and they are just boring. They will not get ahead unless you can work on them, okay? So now let's discuss these point-by-point ideation, okay? So how can you ideate better? So the first thing I would suggest is to read more and talk to more people. So when you talk to a lot of people, you understand the pain points of people and you also gain a reflection of what happens in others' lives, okay? A lot of people, they just know what is happening in their life. They don't know what is going on in others' life and we as engineers, a lot of people are watching this, are probably engineers. So we have a certain perception of the world. It might not be the same as someone else, okay?  Because an entrepreneur is an exceptional being, right? He or she will have a certain thought process which will not be shared by the world, okay? And you have to calibrate yourself according to the world and that can be done by talking to more people. You should also read a bit. You should read some books. You should read news. You should read all of those things because that gives us perspective and it tells us about what's going on in the world, okay? Another thing which has helped me is spending some time alone, observing people, reading the news, trends, and then you can just go on a walk when you go outside. You can think about these things, okay? So that is something that I really enjoy, you know, walking in the grass or going outside in the sun. These things are not only beneficial for your health. I believe that you get a lot better ideas when you go outside in the sun. You walk a bit. You do some exercise. I think it's good for the ideation side of our brain. Always mind your surroundings and a good idea is in combination or it's at an intersection of what you know, what can be a viable business, what people want and what you can do for 10 years because business is not a one-year thing. You will be doing that business for 5 or 10 or 20 years, right? So you have to have the appetite or you have to have the capacity to run for so much time, right? The next thing is building a product. So earlier building a product used to be a big deal, okay? It used to be, you know, people used to go crazy about coding and, you know, we have to code an app or website. Nowadays it is not like that. It is very easy. There are lots of no-codes, SaaS, AI, agency, these kinds of things are their freelancers. Who can build a product for you in just a matter of weeks? So you don't have to be a coder. You don't have to be a technical person. You can build a website very easily using these ways, okay? Another thing which I must say is that you should think about how you can solve your customers' problems, not about the features or the tech of your product, right? Fast and good is better than slow and great, okay? Because you have to launch fast. You have to know where your misgivings were and you have to correct on them, okay? You have to keep on iterating on your idea.  Then we have to leverage. Keep money in terms of debt or venture capital if your business leads a lot of capital for expansion or operation or if it's not profitable initially. You must leverage people. As I mentioned, you cannot work in the business. You have to work on the business. You have to ideate. You have to have the vision. You have to instruct people on how to grow the business. You should not grow the business yourself, okay? That is one thing very important. Your work should only be ideating, okay?  These hires don't have to be full-time people. You can use some tools, some AI, some freelancer, some agency as well. That is also fine, but you should outsource your work. That is important. The last point is discipline and determination, okay? So entrepreneurship is not pretty. A lot of people have made this a very glitched line that, you know, entrepreneurship is not pretty. The money is nice, okay? A lot of people think that startup people are broke. Well, if you are not a good entrepreneur, then maybe otherwise the money thing is nice. But the process of making that money is usually not pretty, okay? It is usually boring. You have to do some sales. You have to do some people management. All of these things are not, you know, pretty like they look in movies and TV shows, okay? It's just boring, plain, simple work, okay? Growth can often be slow, linear, frustrating, okay? When people brag about, okay, 10x growth in one year, usually there is some caveat in that. They have probably burned, maybe they are in a thousand percent loss for that growth. So all of these things are there, okay? It is not easy to grow. You will have to have some patience and you have to be determined in order to continue despite these challenges, okay? But you should not, you know, give away your life just beating up a business side which is not working.  Don't be over optimistic as well. Business is about daily habits, okay? You need to have daily habits that, you know, today we have these, these, these tasks. We will do it, okay? No matter how our mood is, we will try to do as much as we can, okay? There is a certain amount of risk associated with any business activity. It is basically an investment of time and money. So you should understand how much risk you can take and build a business only according to that, okay? Don't take too much risk and don't take too little risk, okay? But you have to understand this very well. Business is risky and you have to have a risk appetite to continue. So how do I learn these things, okay? So the first way of doing it is by learning. And that is like the 90% of the learning, right? You cannot learn business by reading, okay? It is not a course. It is not something, you know, that you read from a book. Books are nice. I will discuss them. But mostly it's by doing. Just launch something. See what happens. If, if it doesn't do well, doesn't matter. You can launch again, okay? A lot of people think that people are judging them. They are not. Everyone is busy in their lives. You can launch something. People will forget about it after one month, even if it's a failed product, right? It doesn't matter. But if you are successful only even once, that can actually change your life. Read books, interact with successful mentors, follow their social media, et cetera. But, you know, a lot of people tend to do this too much. They just keep on reading Twitter and LinkedIn and all kinds of podcasts and books, which doesn't lead to anywhere. You should have some, you know, inspirations. You should follow these things sometimes. Okay. Read when you need to know something. But don't be someone who is just reading business books 10 hours a day and not building anything. Okay. For concrete scales, blogs and courses are good. Okay. Our university division is actually for this purpose only. That's why we built it because this is important. Okay. I even took the entrepreneurship course in IIT Bombay, where I got to learn a lot of these things. However, you should understand that 90% of learning will happen outside the classroom. Okay. Classroom is for theory. Then you have to go and apply these things. All right. Now, my counsel to aspiring entrepreneurs, students who would like to build a startup or company and to people who are not even students and watching this, what would I advise you? First, I would advise you is that you don't have time. Okay. A lot of people are under this impression that, you know, you are young and you have a lot of time.  I'm 24 years right now. I'm going to be 25 next year. And you will not get many opportunities to be an entrepreneur. Okay. I know I'm 25 and I'm saying this, but you have to understand this, that as life progresses, you will have to take up a job after college, you know, and all kinds of responsibilities will start mounting up and then it will be harder and harder to take risks. Okay. I started when I was 17 or 18. So I had my entire college life to build a business. So by the time I was graduating, I had a business which was operational, which was making profit and really good profits. So I didn't have to sit for placements and I could continue on my entrepreneurial journey. And now I'm doing great at my age. Now, if you keep on waiting because you think that you have some time or, you know, you can wait for your after your placements will build. No, that time will not come because you will now start, you know, working on your job or something like that. So don't be, you have to be a bit impatient about this. Okay. College is the best time you don't have much time and you will have a lot of freedom as well. So start now. Start. Just get started with something. Okay. Even if it's a bad idea, according to you, just get started. If you don't, you will regret it because time will pass. And the last thing which I would say is that you should start small, but think big. Okay. Don't think of ideas that you cannot pull off right now. Start with something that can make you a few dollars right now. Okay. It will make you a few rupees. It will maybe make up your pocket money for the month. Okay. Start some with something like this. Slowly you will keep on growing it. And one day you will be making crores and millions of dollars. Trust me, you will. Okay. And hopefully you will do something impactful for the world as well. So thank you. I hope you enjoyed this lecture. You learned something from it. I thank NPTEL and IT Bombay for inviting me and for sharing, for sharing my learnings. If you have any queries, you can feel free to reach me out on my social handles. I'm pretty Googleable. You can Google Kalpith Viva. You can find me or you can email me at kalpith at the rate acadboost.com. Thank you for watching.


I feel like today, people like myself, we have actually the means and the power to fight and it has never been a time in the world actually like that until Bitcoin came in 2008. Everything is possible actually, because money is everything. When Fodig Jop was a high school senior growing up in Senegal, he was accepted to Emporia State University in Kansas to study engineering and to play basketball. But before enrolling, the value of the tuition money his father had set aside was cut in half overnight because of a backroom deal spearheaded by the International Monetary Fund and the French government. So all the money that my dad saved for me to basically go to college overnight was worth 50% less. That experience is what led to Jop's current career as a software developer working to make Bitcoin easy to use as a medium of exchange for anyone in Senegal with a smartphone. Bitcoin is not controlled by anybody, nobody can come overnight and say that now it's worth this much or 50% less or 40% less. So if you're in a country where maybe your money might be devaluated on the whim of other nations interfering with the local economy, storing your money in Bitcoin might be a better deal for you in the future to preserve your wealth and preserve your value. It's providing a parallel store value and a superior one that is not going to be the whim of the French government, the US government, the Senegalese. Senegal has been subject to monetary colonialism since 1945 when France ratified the Bretton Woods Agreement, which gave it control over the currency of 14 African nations. On the morning of January 11, 1994, the CFA Frank, or CIFA, was pegged to the French Frank at a valuation of 1 to 50. The following day it was cut to 1 to 100 after the French government gave into pressure from the International Monetary Fund and World Bank to devalue the currency. Not only did this temporarily crush Job's college dreams, it also led to widespread political unrest, as West Africa's subsistence farmers could no longer afford to import essential goods, including drugs to treat malaria. It was really a big uproar for these African countries, but the local people really found themselves pretty much robbed because your purchasing power overnight was worth half. The cruel irony was that the economic fate of millions of Senegalese was completely out of their own hands. Despite the Human Rights Foundation's Alex Gladstein, no amount of protests could overthrow their economic masters. I went to the embassy, I got rejected. They say, actually, I didn't have enough money, and I was really heartbroken. Job's father was eventually able to pull together the money, and Job got to attend college after all. After graduating, he came across a video featuring a Senegalese scientist and historian who criticized the French-African monetary system. At this time, I wasn't actually very conscious about what really happened. Job says it was the first of three awakenings that set him on his current career path. Every once in a while, a revolutionary product comes along that changes everything. The next was Steve Job's famous 2007 announcement of the iPhone, which ultimately led him to consider how poorly traditional banks serve the citizens of Senegal. Everywhere you go in downtown, there's a bank in every corner, Bank of Africa, Bank of this, Bank of that, Bank of whatever. And for me, I can't help but wonder, I said, with so many banks here, how can we have the lowest number of banked people in the world? Who are these banks serving? The people who actually live in these remote areas have to pretty much travel about two to four hours just to go inside a bank. Job's handheld computer created an opportunity to circumvent these institutions altogether. My vision of the future is that ultimately, your bank account is going to become pretty much your cell phone device. But Job's revolutionary new communication device needed a decentralized monetary system to match, which is where Bitcoin comes in. Reading Satoshi Nakamoto's groundbreaking 2008 paper led to Job's third awakening. When I read the white paper, they said, okay, well, this is a weapon for us to fight oppression. But the Bitcoin network alone isn't well suited to becoming a medium of exchange for everyday purchases in Senegal or anywhere else. It's because it currently has the capacity to process only a handful of transactions per second, which is where the Bitcoin lightning network comes in. So Bitcoin, for it to rival the likes of Visa and MasterCard, it would have to do upwards to like 20,000 transactions per second, or like maybe 25,000, even 25,000. Today, unfortunately, Bitcoin only does seven to about 12 transactions per second. Lightning network works like a bar tab.  So Bitcoin is a base layer, but unfortunately, it's not really fast or nor is it cheap. So basically, what happens is you and I, we open up a channel or like a lightning network channel, you know, basically, we put some funds in there that we'll log, and then we can project as many times as we want, millions of times, basically. At the end of the month, we basically go settle on the Bitcoin layer itself, which is a little bit more expensive because, of course, it's the base layer, but lightning-wise, our transactions will pretty much cost a fraction of a 10. So it's almost instant and almost free. And then at that point, we can rival the master cards and the visas of the world. With Bitcoin, the lightning network and ubiquitous smartphones, Job thinks it's possible to build a new free market monetary system that will finally liberate Senegal and other African countries from the last vestiges of colonialism. I feel like maybe governments are still threatened, maybe. But to me, open-source technology is just beautiful. And I believe actually that our work is so important that we have to do it no matter what the consequences are. So if you can leverage this technology to fight the oppressor, right? And technology, open-source technology is actually what we need right now. And it's here. So why not use it?