I'm excited for 2011, and I want to share some of my plans for the coming year. But before I do, I also feel obligated to take a look back on my plans for last year.
I can't believe a whole year has passed since I wrote a blog post called "Towards a new entrepreneurship" laying out my priorities for 2010. Back then, I wrote:
This idea has become a reality in many ways this year. Our ideas have entered the mainstream of startup thinking and even the popular culture. I mean, who ever thought we'd see this cartoon in the New Yorker magazine?"[Here is] an idea that I don't think is too widespread yet: that entrepreneurship is an industry. Sure, when entrepreneurs create startups that grow up into mature companies, they become part of an established industry, with its own ecosystem, norms, partners and best practices. But until that happens, we entrepreneurs have our own ecosystem, of investors and service providers, norms and even some "best" practices. The two ecosystems have diverged significantly in the past fifty years - and especially in the past ten. The reason is that the underlying theory that powers established business, the theory of general management, is increasingly inadequate for managing startups. And yet, so far, we lack a coherent theory to replace it. My belief is that the lean startup is that theory. Together, we are part of a movement that is redefining entrepreneurship."
Lean Startup Meetups are now in more than 75 cities, with more than 12,000 combined members. More and more, I am meeting entrepreneurs and managers from companies large and small who agree on this one point: entrepreneurship is management. By applying the same scientific principles that gave rise to general management in the first place to entrepreneurship and innovation, we are unleashing incredible creativity. But we still have a long way to go.
In that spirit, I want to review the four priorities I laid out at the start of this year. For 2010, I announced four main projects. Here's how I laid them out (in their original embarrassing order), and here's how each one turned out.
- The Lean Startup Cohort program. Verdict: FAILURE. This seemed like such a promising idea at the time. Take a small number of high-growth companies and have them pay a premium price to learn from me and from each other how to apply Lean Startup ideas in depth. My main hypothesis was that making the program expensive would act as a quality filter, and that if we could find smart, committed companies to participate, they would all benefit tremendously. Thus, I assumed the biggest risk was finding participants who could afford the price.
Unfortunately, I was completely wrong. Finding participants was no problem; the program quickly filled up. And the quality of participants was way higher than I imagined. And yet, when we actually started to run the program, it still failed. Teaching Lean Startup concepts in a fixed order really didn't work, since all active companies face different challenges at different times. And even in a strict, high-quality filtered room, most companies didn't want to share their problems and internal data, nor did they particularly want to engage with other companies' problems. In retrospect, that should have been obvious to me - as an entrepreneur, I would never have had the patience for a program like that.
What's that you say? Even "gurus" have to get out of the building, build a minimum viable product, and pivot? Why, yes, they do. Embarrassing, but at least we failed fast. (Peter Drucker thought people used the term guru because it was easier to spell than charlatan.)
- Teaching in academia. Verdict: MIXED. I started the year co-teaching a Lean Startup class for MBA's at Berkeley with Steve Blank. In some ways, it was a big success: the class was oversubscribed, had a record number of auditors, and received positive reviews. But the experience left me with doubts about whether that is the right way to engage with academia, for me.
I strongly believe academia has an important role to play in transforming the practice of entrepreneurship. Luckily, Steve has been leading the charge to bring a new way of teaching entrepreneurship into academic programs, and 2010 saw the debut of his Durant School of Entrepreneurship at sllconf, as well as new programs like the Lean Launch Pad at Stanfordand the Business Model Competition at BYU.
I believe significant new research also needs to be done. What we know today is just the tip of the iceberg about this new entrepreneurial management. How many of our beliefs are just tactics that sound good, or that only work in certain situations? Much more is needed, and 2011 will see the first few buds of that research project flower. My colleagues at Harvard Business School will debut a new Lean Startup-themed course for MBAs this spring, as well as a new $50,000 Minimum Viable Product Fund. As part of that project, HBS has commissioned a series of new case studies on Lean Startup practices, both in and (importantly) outside the software industry. (You can see a little taste at Jeffrey Busgang's blog here.) I've also begun a collaboration with Nathan Furr at BYU to research actual practitioners, following them over time with an eye towards discovering ways to test some of our beliefs about Lean Startup ideas empirically. You can follow our work (and volunteer to be studied) here.
Also along these lines, I've worked with a variety of collaborators to produce case studies right here on Startup Lessons Learned. Hopefully, more will come in the new year. You can see our efforts so far.
- Startup Lessons Learned Conference (sllconf). Verdict: SUCCESS. This was a project I almost didn't do this year, because the prospect made me so nervous. Boy am I glad I did. I still receive regular feedback from people who were there live or in one of our 60+ simulcast locations around the world. It was always a dream of mine to produce a conference where knowledge - not hype - was king, where information was presented in a useful order, and where success theatre and vanity metrics were banned. I believe we succeeded on all three counts.
In case you missed it, here's a little taste of the event itself, courtesy of my friends at Micro-Documentaries:
And don't forget, you can watch full video of the entire conference courtesy of our sllconf Justin.tv channel.
In 2011, we will do sllconf again, probably in mid-May. As always, I will look to you readers for guidance and suggestions of what we should do different. Stay tuned for details. If you are interested in speaking or mentoring at sllconf 2011, we will accept suggestions and nominations. If you would like to nominate someone, please post a video of them giving a talk (with slides if possible). Grainy low-def youtube videos are perfectly adequate. We had far too many submissions last year on behalf people I didn't know. I had to be confident they would meet the standards I laid out above, but I couldn't take the time to meet them all. Therefore, if you'd like to speak this year at sllconf, a great way to get a leg up would be to speak at a Lean Startup Meetup, and ask someone to record the session. And if you are a meetup organizer, and have had a great speaker who you'd like to see at sllconf 2011, please let me know.
In other conference news, we'll also have an event at SXSW. We'll make details available soon, I promise. If you're going to be in town for SXSW, and might like to join as a speaker, sponsor, or attendee, please let me know.
- Writing a book. Verdict: TBD. I am in the final weeks of preparing a manuscript for The Lean Startup Book which will be published by Crown (one of the largest business book publishers in the world) in 2011. I sincerely hope you'll like the final result; it has been a labor of love for me all year.
Deciding to publish this book through traditional channels took a lot of thought. I believe it is time for our movement to Cross the Chasm into mainstream awareness. Our early successes have been impressive, but we are still just at the beginning. In my talks all this year I have been exhorting audiences to Stop Wasting People's Time. Our modern economy is full to the brim of waste: building products that have few customers, that produce negative returns for investors, or companies stuck in the land of the living dead. And yet, the people who are responsible for this waste are not generally early adopters of new ideas about entrepreneurship. They are not scouring blogs for the latest gems in innovation thinking. They are overwhelmed, doing the best they can, and get information from only a few sources. They don't want avant garde advice, they want to be reading the same things everyone else is reading.
My belief is that, in order to reach this mainstream audience, we need to produce a book that is accessible to them, and then make that book a bestseller. That's one of my main goals for 2011, and I will be asking you to help many, many times in the coming year. I hope you'll continue to support me as you have this past year.
As a reader, the rational thing to do with a new book is to wait until the book comes out, see if your friends and colleagues read it, and if they do, see if they think it's any good. That's classic mainstream customer thinking. Hopefully, the early adopters and visionaries among you will disregard this advice, and agree to pre-order the book instead. The more of you who do that, the more people we'll be able to reach when it debuts next year. Remember, mainstream customers will be looking to you to see if it's worth buying.
You can pre-order it from me directly, or get an even better price at Amazon.
(If you'd like to help, I'm still looking for test readers, case studies, and - most importantly - help bringing traffic to the book website. We're running constant A/B tests there; anyone who is able to donate traffic, ads, or a link from your own blog/website will have my gratitude.)
So that was 2010. I believe 2011 will be even better.
It's an auspicious time. Entrepreneurship is in a new renaissance. There are more startups operating today than at any time in history. New ideas about entrepreneurship are in the air. And the dominant management paradigm of the past century has run its course. Literally.
2011 will mark the one hundredth anniversary of the idea of management. I date its origin to the publication, in 1911, of Frederick Winslow Taylor's The Principles of Scientific Management, one of the most important management books ever written. Management's second century will be very different than its first. Our problems are more complex, faster moving, and we face greater uncertainty. In other words, we need entrepreneurs to solve them. I'm excited to see what comes next.
I hope you've all had a happy holidays, and I wish you the best for a new and exhilarating New Year. Here's to 2011!
Two quick things:
The report provides some statistical observations for 2010.
Top Trends in 2010
Web Security: For 2010, the average number of new malicious websites blocked each day rose to 3,066 compared to 2,465 for 2009, an increase of 24.3 percent. MessageLabs Intelligence identified malicious web threats on 42,926 distinct domains, the majority of which were compromised legitimate domains.
Spam: In 2010 the annual average global spam rate was 89.1 percent, an increase of 1.4 percent on the 2009. In August, the global spam rate peaked at 92.2 percent when the proportion of spam sent from botnets rose to 95 percent as a new variant of the Rustock botnet was seeded and quickly put to use.
Viruses: In 2010, the average rate for malware contained in email traffic was 1 in 284.2 emails (0.352 percent) almost unchanged when compared with 1 in 286.4 (0.349%) for 2009. In 2010, over 115.6 million emails were blocked by Skeptic representing an increase of 58.1 percent compared with 2009. There were 339.673 different malware strains identified in the malicious emails blocked. This represents more than a hundred fold increase over 2009 and is due to growth in polymorphic malware variants.
Phishing: In 2010, the average ratio of email traffic blocked as phishing attacks was 1 in 444.5 (0.23 percent), compared with 1 in 325.2 (0.31 percent) in 2009. Approximately 95.1 billion phishing emails were projected to be in circulation in 2010.
The report says It is predicted that in 2011 botnet controllers will resort to employing steganography techniques to control their computers. This means hiding their commands in plain view perhaps within images or music files distributed through file sharing or social networking web sites. This approach will allow criminals to surreptitiously issue instructions to their botnets without relying on an ISP to host their infrastructure thus minimizing the chances of discovery.
What are you planning on doing in 2011 to minimize the impact on your network and to prevent your computers from being the victim? What do you anticipate your biggest threat to be for 2011?
Deb Hale Long Lines, LLC (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.
first I want to wish you all a good start into this new decade.
Then I wanted to inform you about some news for Zend Framework.
Within the last days I began a complete rework of the I18n core for ZF.
The first class which will be reworked is Zend_Locale as it’s the base class for I18n within ZF.
The following changes will be done for Zend Locale 2.0:
CLDR update to 1.9
This integrates the most actual locale database within ZF
Usage of a fallback locale
This locale can be set and used as fallback when the wished locale is not supported
Usage of a fixed locale
This locale can be set and will be used regardless of any other locale which the accessing user wants
This removes the workaround from Zend_Application
Add locale providers as base
This allows to use other locale providers than CLDR
This will remove Zend_Locale_Format and integrate it into the used provider
Rework CLDR to be a provider
Add INTL as new provider
This allows to use INTL when available alone or in combination with CLDR because the INTL extension does not provide all informations like CLDR
Add a way to upgrade a locale
This would allow to provide informations for language locales when no region was given (f.e. when a user gives ‘en’ and wants to have informations from a region (f.e. currency))
Add script support
This allows to use locales which provide several scripts within the same language like Azerbaijani, English or Hausa.
That’s the actual plan for Zend_Locale 2.0 and will be the base for all other reworks.
Please note that all spoken will be done within Zend Framework 2.0 and not be migrated to 1.x.
I18N Team Leader, Zend Framework
Zend Framework Advisory Board Member
Zend Certified Engineer for Zend Framework
It’s been a while since I’ve written a technical post, so I thought, maybe I should write about what I’ve been working on for the past couple months…
I’ve been building a test and development infrastructure for The Wikimedia Foundation using OpenStack, and a number of other technologies. I’m not done yet, so I won’t get into any gory technical details (I promise I will later!). I will, however, give an overview of the architecture I’m aiming for.
We want a test and development infrastructure for a number of reasons:
- We’d like to replace the Tesla infrastructure I built for the Usability Initiative project
- We’d like to have an infrastructure where we can let volunteer developers and staff work collaboratively, and easily build infrastructures without relying on the limited resources of the (overworked) operations team
- We’d like to be able to run realistic tests of our operational infrastructure so that we can be better prepared for outages, and so that we have an environment to safely train new operations staff
- We’d like to have an infrastructure we can use to vet operations volunteers before we allow them access to the operational infrastructure
- We’d like to have an infrastructure where developers can easily have root
With the above goals in mind, the infrastructure needs to handle most things automatically. We (operations) don’t want to have to manage user accounts. We don’t want to have to create virtual machines for people. We don’t want to have to manage DNS entries, or IP addresses. We do want an infrastructure that is close to our production environment, but is flexible enough to let developers add infrastructure without our help. We do want an infrastructure that lets developers prepare their projects for running inside of the production cluster by using the exact same processes as the operations team.
I’m creating an infrastructure to handle this, and here’s the basic architecture:
- OpenStack as the virtualization technology
- Four nodes: 1 controller node, and 3 compute nodes (should be able to run roughly 100-120 VMs)
- Handles VM creation and scheduling on compute nodes
- Handles IP address allocation
- Has EC2 and Openstack APIs
- Gets user account information from LDAP
- Stores IP/VM information in MySQL
- PowerDNS with an LDAP backend for DNS entries
- Currently using “strict” mode for this
- Each VM gets a DNS entry based on the name of the VM, and a cname record based on the “instance id” provided when the VM is created
- Can handle multiple DNS domains
- Puppet with an LDAP backend for puppet nodes
- Node entries stored in LDAP so that users can easily select server types when creating VMs
- Puppet manifests, files, and templates stored in SVN or git repository
- Everyone with an account will be able to modify puppet, but changes will need to be merged into the main branch by an operations team member
- Ideally branches can be merged into the production cluster’s puppet repository as well
- MediaWiki as the virtual machine manager
- Manages VM creation/deletion/modification, DNS, Puppet, user accounts, sudo access, user groups, user SSH keys, and OpenStack projects
- Using the OpenStackManager extension and the LdapAuthentication extension
- Progress on this is going well. Basically I just need to add localization and more error checking for this to be at a usable level (if you’d like to help with this, please do!)
User account and project management
From an operations perspective, the big thing for this infrastructure is that it is low overhead for us. We’d like to empower our community without overburdening us. A big part of this is not having to deal with user accounts, authentication, and authorization. Here’s how I plan on solving this problem:
User accounts are created and maintained by MediaWiki. MediaWiki will use the LDAP Authentication and OpenStackManager extensions. Wiki admins will be able to create accounts for other people. When the account is created, it’ll automatically get an account on the VMs and in OpenStack, as the account will be created in LDAP, and everything in the infrastructure, excluding project wikis, will use LDAP for user accounts. They will also be added to a shared default group, which will give them non-root access to the default project. root access will be granted on an as-needed basis by the operations team in the default project. In this environment, they’ll be able to participate in any default-group shared projects. They will not be able to create VMs.
OpenStack has a concept of “projects”. When a user is added to a project, they have the ability to create, delete, and manage VMs in that project. The default project will be maintained by the operations team. It will be a clone of the production environment. Access to this OpenStack project will be limited. Instead, we’d like real projects (like Usability Initiative, or Pending Changes, or OWA) to have OpenStack projects created specific to the real project. In this project they can create VMs, and maintain separate infrastructure from the default project.
OWA is a good example of when VMs would need to be created for a project. OWA needs LVS, Squid, Apache, MySQL, and a few other things. It runs differently than our current infrastructure, and could require changes that could possibly break other things. For this, the initial configuration could be totally done within a separate set of VMs, where once configurations stabilize they get moved into the default project.
Project management will be handled via the OpenStackManager extension. Anyone in a project will be able to add/remove users to/from the project. Each OpenStack project is also a MediaWiki namespace, and a posix group on all VMs. Though everyone will have access to the default project VMs, only people added to other projects will be allowed to access the VMs in those projects. Users in non-default projects will also have sudo rights automatically granted to them on those VMs.
Access to VMs will be limited to SSH key authentication. Users will be able to manage their own SSH keys via the OpenStackManager extension. These keys will be managed in LDAP, and VMs will sync the keys to the user’s authorized_keys file.
VM, DNS, and Puppet management
The other part of not overburdening the operations team is for VM, DNS, and Puppet management to be mostly hands off. Currently, with the Tesla architecture, I need to create VMs from scratch, configure them, add user accounts and groups, and add users to sudoers. I also need to assign an IP address and add the VMs to DNS. Once a team believes their project is production ready, if there are architecture changes, I need to add those changes to puppet, and recreate the architecture in our production cluster. This is very time consuming. Ideally, most of this can be handled by the developer, and that’s what I’m aiming for with this infrastructure.
When a new project is formed, an operations team member will create an OpenStack project via the OpenStackManager extension, and will add a project member to it. After doing so, that user can add other users to the project, and can create their custom architecture. They’ll be able to go to an interface to create their VMs. When creating the VMs, they’ll be able to name them, give them a size (CPUs, memory, disk space), and manage puppet classes and variables. The puppet configuration will allow them to create VMs that are already pre-configured as specific types of VMs. For instance, if you want a VM that is configured like our Application servers, you’ll simply need to add the “appserver” class.
Once the VM is created, the OpenStackManager extension will add the DNS information and Puppet information to LDAP. When the VM is finished building, it’ll automatically sync user SSH keys from LDAP, configure itself using puppet, and will be available for SSH login.
Everything we do in the production cluster now occurs through puppet, and we’d like developers to do the same thing on their VMs. Though the OpenStackManager extension will only allow selection of configured classes and variables, that list will be managed in the puppet configuration that will be managed through SVN or git. Developers can create puppet manifests, files and templates, and can add them to the repository. The operations team will maintain the main branch, and will merge changes in. When it is time to move a project to the production cluster, we should be able to merge that puppet configuration into our production puppet repository, allowing developers to be part of the process from beginning to end.
We have a pretty annoying problem on Tesla right now. Most projects are sharing the Prototype VM. Some projects use the trunk version of MediaWiki, others use the deployment branch. Most projects share the same extensions directory. This causes problems where projects often break each other. Also, the Prototype VM isn’t configured like the cluster, and as such, code deployed from this environment may run into unexpected issues. A goal of this new infrastructure will be to solve this problem.
Ideally, most projects won’t need to create their own infrastructure for testing. Most projects are just creating MediaWiki extensions that should run perfectly in our existing infrastructure. What developers really need in this situation is a wiki with a full copy of the extensions directory. They need to be able to create a wiki with a choice of either using the deployment branch, or trunk. They need to be able to limit access to their wikis to people in their project, if it isn’t a shared project. They should be able to create these wikis without root access. They need this wiki to run in an environment that is configured as closely to the production cluster as possible.
My plan for this is a script on the default-project, that will run via sudo, that will automatically check out from SVN, create the wiki’s database, and add the wiki to the Apache configuration automatically. It’ll set up the file permissions automatically for a shared-wiki, or a project wiki. Access to these wikis will be controlled via OpenStack projects, which are also posix groups. This gives each project a little flexibility too, as if they later decide they do need a VM for testing, they’ll be able to create it.
Want to help? Have an idea to make this better?
I’m still fairly early on in the process. I’ve built a lot of the infrastructure, and am mostly done with the OpenStackManager extension, but the infrastructure hasn’t launched, and things can still be easily changed. If you want to help, or have ideas on how this can be done better, I’d love to get some help. If you’d like to help with the operations portion of this, I’d love help with that too. It’s a great learning experience, and I’m testing and developing this in the Tesla environment right now, so I can give out access fairly liberally. Even excluding the virtualization part of the infrastructure, we’ll be building a clone of our production environment mostly from scratch, which will be a great learning experience. It isn’t often you get to build something like this from scratch, so if you are interested let me know!
I’m hoping to have something that is at least ready for basic use by mid or late January. Full implementation of my above plan will likely take a few months though. With help I can probably get it fully ready much sooner.<#comment hash="f92e3f4a596ee1383542fa82e3050512" /> <#comment hash="9d6ee31bc358db3224830f8469fa13c0" />