Funding free software projects

Friday, November 21st, 2003

Successful open source projects are usually initiated by someone with a clear vision and also the knowledge to set about turning that vision into reality. But what happens when someone has an idea and also has the resources to hire programmers to execute that idea?My experience with SchoolTool v1
This note was inspired by Tom Hoffman’s blog entry which referenced SchoolTool and Chandler. I thought he was touching on a subject which has interested me for some time – how best to fund open source development. Trust me this is not easy. Most open source projects are led by the person who had the original vision. It’s much harder to HIRE people to work towards your own vision. But if philanthropists are to invest in open source software, then we have to figure out how to do just that.

First, some more history on the SchoolTool project, because I think it nicely illustrates the phenomenon.

I hired a talented and diverse team to build SchoolTool just as I was heading to Russia to see if I could get into the Russian space program. All of the team members were familiar with and fans of open source software and open source development. There was no one at the Foundation that had experience managing an IT project, but I figured the that the team would have no trouble managing itself. They should have the best of all worlds, with steady salaries to allow them to focus their time exclusively on an open source project. Most open source projects are part-time efforts, with the team members constantly constrained in the time they can devote to their “hobby”.

While I was in Russia, the team sent me a series of regular reports on their progress. They settled on Java, not an environment I like, and SQL database, a reasonable proposition. So far so good. But over the next few months I noticed that they were spending a lot of time solving problems that didn’t really need to be solved. For example, we wanted SchoolTool to be cross-platform. They invested a huge amount of effort designing an XML-based UI description system, which would then automatically generate a UI for each platform. Why reinvent XUL, I asked? It seemed as if, given free reign, the developers pursued their own personal interests rather than the goals of the project. Sure, they could always argue that the tools they were developing were ultimately going to be USED by SchoolTool, but I was always left thinking that if I were in their shoes I would want to start solving the unique problems of school administration FIRST, and leave some of the other niceties till later.

After a while it became clear to me that the team was not going to produce a functional tool. So I canned the project and shutdown the development office, letting the developers go. This was a very unpopular decision, quite a few educational groups had pinned their hopes on SchoolTool. Rather than keeping those hopes artificially alive I killed the project outright and said we would not develop SchoolTool further. But at the back of my mind was still the belief that SchoolTool is a project that is both feasible and worthwhile, and that it should work in an open source environment once it has critical mass.

The issue, as I see it, is leadership. Most open source projects are founded by one or two people who have a very clear idea of what they want to create and how they plan to do so. They have an itch to scratch. Once they have a basic framework together, other people start to use it and the stone soup effect kicks in… some of the users become developers, and the bazaar magic happens. But here’s what’s critical – the success of the project continues to depend on it’s leadership, usually by the founders but sometimes in a more institutional way (like the Debian project).

Contrast this with my experience of hiring developers who had great skills but no personal attachment to the idea of having a SchoolTool out in the wild. They did what all open source developers do – they scratched THEIR itch.

In a proprietary development scenario the company and hence the developers are driven to ship product – they get no sales without a shipping product, and thus no salaries without shipping code. So there is an urgency and a pressure to ship something. We have all seen that sometimes that pressure is not constructive, and code is shipped in barely working state. Contrast this with open source developers who want a good, working tool out there – they ship it when it’s “done”. But that assumes that they really want it out there. If they are simply being paid to cut code, they cut the code they find most interesting, not necessarily the code that is on the critical path to ship the actual tool they’re working on.

Recognising this, I decided to cut the code myself. The two month hiatus Tom describes was part of this time, with me trying to recreate the good old garage days when I could spend all day working on the code that ultimately became Thawte. It took me that long to realise that times have changed – life’s too good these days. Try as I might I don’t have the self-discipline to shut out the rest of the world when the phone keeps ringing, email keeps flooding in (although I did learn to ignore most of that, a useful exercise) and there are limitless opportunities to do fun stuff. I quite enjoy life as a retired cosmonaut with some financial security, but that enjoyment comes at the expense of focus. So much for plan B, what would be plan C?

I decided to hire the best Python developer I could to lead the project, then hire one or two other teams to work in collaboration with that core team. Hence my search for and appointment of Steve, Marius and Albertus.

How will we avoid a simple repetition of the previous problem? What makes this effort different? Nothing, so far. We once again have a bright team of developers who are at the end of the day motivated by a contract, not by a personal itch in education administration. But this is only the story so far. The next step will be to hire an additional team to collaborate with Steve’s. It may seems strange to hire a separate team rather than bolster the core one, but there’s method in my madness. Right now, a lot of the critical thinking and discussion happens inside an office in Vilnius, with no reference to the rest of the world. That makes it efficient, but not necessarily effective, since it may be efficiently going down the wrong road. Steve’s been pretty good about going to the list to get a sense of how different educational communities work whenever they start work on a new section of the project, for which I’m grateful. But the problem still remains – a lot of SchoolTool development happens in a non-transparent manner. By hiring a second team to collaborate on the core infrastructure I hope to force these discussions to happen online – in the mailing list and in wikis etc – in a way that makes them transparent and accountable. That way outsiders will be able to comment, and more importantly, we will be able to go back and understand what was decided, and why.

As for directedness, I came away from my visit to Vilnius with the impression that Steve really wants to see SchoolTool reach its full potential. There were some slight alarm bells (the dev team spent a lot of time showing me what their engine COULD do, and I spent a lot of time shifting the discussion back to what it DOES do), but at this stage I think we are still in reasonable shape. Perhaps we should actually have one or two schools that will deploy their work, to keep their debates grounded in the real world… but that can come in due course.

Lessons Learned
So the risk is that a well-funded open source team that is NOT led by someone with a personal interest in shipping the project will get distracted by other shiny tech toys and fail to actually ship something focused and constructive. How are we dealing with that in the current round of work on SchoolTool? First, I’m personally watching and asking the core team to focus on actual functionality. They assure me that their engine work is “done”, and that they are currently working on a usable tool that can be tested by schools. Time will tell. And second, we will shortly have a second, collaborating team, that will I hope also bring much of the engineering work into a more public forum.

Time will tell. These are expensive ways to learn, but I feel that the experiment is very much worth doing. There are lots of tools I would like to see developed in the open source world that developers have not yet done for themselves, and which I would be prepared to fund. Perhaps other philanthropists are in a similar position. We need to learn how to do this effectively, and the only way to learn is to try.

Update: 2003/12/3
A further email exchange between Tom Hoffman and I went along these lines:

Tom: Coming up with an RDF version of your REST api is definitely luring me as a shiny geek toy, of the type Mark wants you to avoid getting sucked into. I’ll start trying to delve into it though.
Me:The beauty of the open source process is that non-core developers ARE willing and able to play with shiny geek toys. It’s the core team that I need to keep focused, they set the release schedule and core functionality / infrastructure pace of development. But the fact that outsiders are able to think laterally, and experiment with code that can be proven outside of the main development process is what gives open source its real diversity and amazing ability to innovate. So as long as it’s not on my dime, please scratch whatever itch interests you most ;-)

I didn’t make it clear originally that I was mainly talking about the CORE development team, which in most projects stays pretty focused on getting the job done using the chosen infrastructure rather than very “shiny” rewrites. The beauty of open source development, however, is that non-core developers can spend as much time as they want experimenting, and it’s this experimentation which can result in dramatic and unexpected features being innovated outside the core tree and then incorporated once they are proven. We don’t want to stop geek playfulness at all, we want to encourage it, but we need to keep the core team focused on getting the infrastructure reliable, usable and regularly released.

63 comments:

  1. Lenn van Niekerk says: (permalink)
    February 10th, 2006 at 5:45 am

    HI, I need to understand how to commincte an idea related to educational and training for all mining employees in South Africa. The thinking is, a group of mining houses, computer manufacturer/s, airtime provider, soft ware manufacturer and a call centre to pool resources in order to make this idea work. My contact number in South Africa is +27 082-804-1302 or office 011-411-2299. Thanks Lenn van Niekerk from Harmony Gold Mine.

  2. Phil says: (permalink)
    February 14th, 2006 at 4:21 pm

    Does this really differ from the traditional development situation? Again you have one person with a vision, and many others who will go off at a tangent at any given opportunity. I’ve seen plenty of developments projects disappear up a black hole of making new widgets and ‘geek tools’ as you call them without producing anything that actually gels and forms a solution.
    Again, you admit that it’s the innovation that we need from these people, and this is why we employ them – whatever the arrangement.
    Surely it’s the visionaries that are missing the trick; structuring the project to allow innovation without losing sight of the core vision? Generating buy-in and excitement about that vision. Good working practise like code reviews, design reviews etc.
    I’m all for the garage approach but all it does is neatly avoid the issues of working as a team. So is the problem the geek or the geek hirer?

  3. John Tapsell says: (permalink)
    February 14th, 2006 at 4:39 pm

    I’m a PhD student, so money is fairly tight. I’m an the maintainer of several KDE apps, and love coding, yet I do actually finance people to do the occasional thing. What works for me is to have a direction I want to go in, and then pay people to do specific tasks. Then I lead and glue the bits together (or even pay someone again to glue the bits together). That way I can lead it and know exactly what is going on, and any task I pay for is done within a week (since the bits are fairly small).

  4. Daniel says: (permalink)
    February 14th, 2006 at 4:42 pm

    I think the issues addressed here are common across closed source and open source projects. From my experience the successful projects (i.e. Linux, DSPAM, Mono, npgsql, NHibernate) have very strong leadership with clear vision in mind. Very often I find open source projects that don’t even have a basic road map defined.

    I hired sub contractors in the past, and unless they have the same itch as the person leading the project (sponsor, leader, stakeholder) things often deviate from the plan. In similar scenario lot of time is spent recreating the wheel intead of reusing as much as possible existing technology out there.

    The challenge is that it takes a lot of time to research and evaluate the wast universe of open source technologies and then come up with plan how to integrate and/or reassemble the many frameworks components into coherent application. For this, a special talent is required. Or so I believe. :-)

    I worked on projects where we had to integrate 5+ different open source technologies (Log4net, NHibernate, IMAP, SMTP, MySQL, Dottext, Lucene.NET – http://www.uniblogger.com), but they all had to be tweaked, the most time was spent reasearching if this could be pulled off at all. Once we had a basic prototype it was just a matter of defining the API interfaces, fixing some protocols, and the actual implementation too less time then the overall plan.

    Cheers.

  5. Peter Krantz says: (permalink)
    February 14th, 2006 at 4:49 pm

    Mark, it sounds like you should have a look at Scrum. Self-managing teams require a vision and methods to help them inspect and adapt to the real world. They also need to work in a way that makes their progress transparent to you. Without such methods you will have no idea what they are doing (I mean really doing – not creating visions about what they will do) and the team itself will not know when they are done.

  6. James says: (permalink)
    February 14th, 2006 at 4:52 pm

    Sounds like you need a Business Analyst and/or Project Mgr to help keep the development on track. Many programmers play the part of BA/PM in their own work, or when the project is small enough that the additional staff isn’t warrented, but when you have a team of programmers working together, it helps to have a dedicated person who can focus on the forest, while the programmers focus on the trees.

  7. Nicholas says: (permalink)
    February 14th, 2006 at 5:16 pm

    “I hired a talented and diverse team…just as I was heading to Russia… I figured the that the team would have no trouble managing itself.”

    Seems to me that this might have been not the best scenario for _any_ type of successful development — open-source or otherwise…

  8. Russell Nelson says: (permalink)
    February 14th, 2006 at 5:19 pm

    Yes, I’ve noticed some of the same problems at the Public Software Fund. Money isn’t sufficient — you still need leadership. Some of the projects have been successful because we paid developers to scratch their own pre-existing itches.

  9. jim coffey says: (permalink)
    February 14th, 2006 at 5:21 pm

    One way to focus an individual and a team on core deliverables is to set clear performance bounties. Cash, pizza, recognition, weekend getaways, whatever motivates your team members.
    1. Install in school #1 – get a bounty
    2. Solve the top 10 problems with school #1 to the satisfaction of the school users – get a bounty

    Fix their compensation so that they have barely enough to live on … and several pots of gold at the end of the rainbow.

    “Nobody gets paid until the customer is happy.”

    Another method of getting extreme effort is competition.

    Set up two parallel teams.
    First to install gets a bonus.
    2nd to install in a school gets a small bonus

    Then let the two schools look at the other schools solution.
    If school A thinks the school B has better software and wants to switch – give the winning team a big bonus.

    Repeat as needed to scale up to an enterprise … to an entire country.
    Repeat to make it small, light, and easy to deploy in a village.
    Whatever fits with your goals as project leader.

  10. Dan Scott says: (permalink)
    February 14th, 2006 at 5:25 pm

    The focus on functionality first violates the user-centered development principle of getting the design right, then implementing the design. You can have all of the functionality in the world, but if the interface design is wrong, then your targeted audience will reject the tool outright… and your interface can be completely non-functional (paper prototypes, for example). Then you iteratively build prototypes that you test with your targeted audience, filling in the functionality behind the scenes and tweaking the design as you incorporate more feedback. This also gives you artifacts that you can share with the community for their feedback.

    Lotus Notes is an incredibly powerful groupware application, hampered by default interfaces that are not very usable. Outlook and Exchange, on the other hand, are catching up in functionality but have focused on ease of use from the outset.

    At least, that’s how it works in the ideal world…

  11. gtonic says: (permalink)
    February 14th, 2006 at 5:28 pm

    These are very good observations!

    Actually I think there are two main things that influence OS Development and make it to differ from ‘closed’ one:

    - Open Source Development means that you’ve to show off your code one day. So you tend to polish your code and try to go the stylish way instead of ‘hacking it’ and getting it done. Well you see, …

    - There isn’t that pressure. SchoolTool won’t bring you any money, it won’t be a cash cow you depend on. Also the guys do know they will earn the money, even the project ressources aren’t that strict – there seems to be enough of time and money, so they focus on what they call quality, while misinterpreting it with ‘stylishness’.

    Do you (or does anyone) agree?

  12. Robin van den Heever says: (permalink)
    February 14th, 2006 at 5:38 pm

    Hi Mark
    We developed a fully functional school accounting system in PHP/MySQL for South African conditions that I want to release as open source, but do not have the resources to do it can you make any suggestions. Maybe I can donate the codebase to some project that you know of?

    With Ward Regards

    Robin

  13. Zeno Davatz says: (permalink)
    February 14th, 2006 at 5:45 pm

    Interesting Article but not very interesting. I believe that is why the Linux Kernel is so successful. Because Linus Torvalds did have and still has a personal itch. You need to make “The Itch” personal to motivate as a leader. I guess that is what ‘Mr. Thwate’ is doing with Ubuntu.

  14. Chris Laprise says: (permalink)
    February 14th, 2006 at 5:46 pm

    The original effort you describe seems to have lacked professionalism. I think two mesaures that could assist in this area are:
    1) Place emphasis on documenting the project’s requirements and use-cases; the former keeps devs focused on the end result, and the latter keeps them focused on user habits and expectations. They are two sides to the same coin, and most OSS projects lack at least one.
    2) Adopt an iterative development process like RUP, which moves implementation of requirements up-front toward the beginning iterations according to their level of risk. Reconfigurable UI would have been lower on the list since a) it didn’t directly satisfy core use-cases above, and b) as you pointed out XUL (and probably others) already exist. If there are no unique technical hurdles posed by the project, then business logic features must automatically be prioritized to the front. Ex: If the members of your audience are suggesting data sets and forms that don’t quite match and reconciling them seems difficult, then designing and testing schemas to satisfy them could be moved to one of the first iterations.
    Also, iterations and phases are by nature easily mapped onto a project schedule.

  15. Kevin Cullis says: (permalink)
    February 14th, 2006 at 6:00 pm

    Mark, it would seem that the original programmers had customer focus: themselves, i.e. as you correctly stated, THEIR itch. However, it sounds like you’ve substitued the programmer’s being the customer to a “Project Manager” becoming THE customer. Rather, the true first order of business: the REAL Customer, the schools! It is WHO are you designing for that makes the difference.

  16. Russell Cole says: (permalink)
    February 14th, 2006 at 6:27 pm

    I think the narration of the problem you expose reveals more about the potentials of open-source coding projects than any possible deficits that are associated with these various forms of social-knowledge production. The problem with the first team of programmers was not its lack of focus; rather, it was your own impulse to direct the outcome of what is inherantly a democratic process that does not lend itself to any pre-established boundaries and demarcations concerning the type of technologies that are created. Open-sourcing is not a valuable social resource simply because it is more efficient, but because it instantiates properties that are connoted with socially democratic processes involved in the egalitarian construction of policy intitiatives, which are conceived and shaped in a manner that reflects the input and voluntary decision-making of all of the members of the project who are also impacted by the project’s developments. The real problem that you disclose is the tendency of some to attempt to impose corporitist ideological restrictions on what should essentially be a system with an indeterminable outcome.

    Russell Cole

  17. StarScream says: (permalink)
    February 14th, 2006 at 6:38 pm

    The first SchoolTool Project sounds a lot like a project that I was involved in at my company. I won’t go into specifics but basically the application was a re-write of an existing app, and the developers were determined not to let the pitfalls of the old system creep into the new one. This wasn’t an open source project, and we were being paid ( and we had deadlines) yet we still managed to sneak into the same problems that happen when your not interested in the actual project. The project is launched now an working well, however it still took a_long time to get to market, and I think that one of the reasons was not that we didn’t have leadership, but that we didn’t have goals that were finite. For example, we said by week 3 we would have a page rendering system up and running, week 8 menu generation etc… however we didn’t have a finite list of functions these had to perform. Which in turn meant we were constantly looking at the code saying, well yeh it “can” do this if you give it xyz….and it could. But xyz wasn’t finished yet, and neither were half of the other components. So what you end up having is a bunch of working “pieces”, but nothing developers or anyone else can physically see coming together. In the end the days just drag, and you can’t get motivated to work or to concentrate on what you are doing. What motivates developers is seeing things come together, so a process which can do this quickly without sacrificing the modularity of the application would yield better results. IMHO. I don’t believe that just having a “manager” is enough, and i don’t always believe a manager is needed. I think teams can work together towards a common goal if they can see it getting closer.

    my 2c. Great entry , and Kubuntu rocks!

  18. unwesen says: (permalink)
    February 14th, 2006 at 6:56 pm

    While I agree that developers pursue the development of shiny geek toys and generally want to scratch their personal itch, I also want to leave a few remarks about the developer’s perspective.

    In a commercial development environment, there’s not enough time. For anything useful. Deadlines force you to implement features in a given order, regardless of how sensible from a technical point of view that is. If two features A and B are sufficiently similar, it is sensible to base them on a base implementation C which A and B mereley clarify on in a specified manner. Speaking in terms of object-oriented code, the classes A and B would both derive from a class C, which implements all of the shared functionality. So far, so good.

    The problem is, that implementing C and then A on top of C will most likely take longer than implementing A without a shared base. The reason is obvious: in implementing C appropriately, the developers have to think hard about what parts A and B share, and how to specify C such that A, B, and possible a far-away feature E might be implemented on top of C. That thought takes time.

    The reality in software-development seems to be that managers want A to be finished in the timeframe that would be necessary to build A on its own, but have it built on top of C. That just doesn’t work. Good managers try to find compromises, but hardly any manager will allow developers to develop a compromise and come back later to the code to clean it up.

    Quite often, though by no means always, the reason why developers decide to build an XML-based UI layout engine is not so much that it’s a shiny geek toy or an itch to scratch, it’s because one is required to make future problems ‘already solved in principle’.

    Here’s another reason: XUL sucks. That’s not really meant as a statement about XUL, I hardly know it and can’t comment. It’s work experience.

    When implementing a given feature, developers tend to program just what’s necessary to solve their immediate problem. In the terms of the cleverly named features A, B, C and E above, when developers need to finish A in a set timeframe, they will not waste thought on how an implementation of A might affect B. In other words, C is never born, and E has to reinvent the wheel yet again.

    Third-party libraries seem to either be an A not based on C, or legacy code with hundreds of kludges and workarounds that make coding with it pretty damn awful. Very, very rarely does one find a C to work with, and that’s usually the third rewrite of an originally pretty nifty idea, which only after two attempts has managed to balance flexibility, usability and avoiding bloat. XUL might be such an ideal library/framework/technology to work with, but quite often third-party code isn’t. So often it’s easier and more efficient to write “yet another “.

    Of course, I’m being polemic here. I’m trying to make a point ;)

    On a related topic, quite a lot of open source and free software is crap. I’m not complaining here, I happily use a lot of it myself! But it does not often satisfy the requirements of commercially developed software (and, of course, a lot of commerically developed software is so bad that noone would dare put it under an open source license). I’ve had my share of experience with reading open source code, and sometimes it was a pain. More often than that, it made me vaguely uneasy, and rarely it made me think “wow, I’ll let this piece of code handly my problem and rest well”.

    From my own experience, the best open source projects seem to be those which have been developed commercially as a basis or framework for a commercial product, but with the intention in mind that the code should be seen and maintained with the aid of the FLOSS community. Qt is a good example. It has it’s flaws, like all code does, but it is cleanly designed, well-structured, easy to use, and has few dragons. And I’m not even a big fan of Qt, it’s just the first example that came to mind.

    With all the above in mind, I would assume that the best compromise between delivering features and code quality you would get is when you commercially develop open source software, and plan to make money selling either a slightly beefed-up enterprise version of the software or maintenance contracts.

  19. Jon says: (permalink)
    February 14th, 2006 at 7:06 pm

    This hits at the very core of the Technical industry and probably humanity. No autonomous entity drives towards goals not directly beneficial to them. In this case, the developers on SchoolTool wanted to get paid to develop a cross-platform GUI that would get them “tech cred”.

    An unguided dollar is a wasted dollar, beit at home, work or global economics. Without a doubt, everyone learns this the hard way. The best way to manage your funded projects is one of two ways:

    1.) Do it yourself. This tends to be the ‘start-up’ method, everyone thinks it’s the path of least resistance. In reality it tends to get a strict result, very few innovations develop out these because it’s hard to convince yourself to expand or take a risk.

    2.) Hire a qualified (if not certified) Project Manager. Pay them for results, not a salary. I pay my IT contractors on up-time and the net result is excellent.

    As a side note, remove chairs from the conference rooms for meetings. It keeps people on task and everyone volunteers for action items. :)

  20. Stephan Wehner says: (permalink)
    February 14th, 2006 at 7:08 pm

    I think it is quite obvious that the article does not explain what was wrong with the first round of the SchoolTool development. “After a while it became clear to me that the team was not going to produce a functional tool.” is not quite enough. It is not clear that the developers were actually on the wrong path. Maybe their “XML-based UI description system” did make sense. This is not addressed convincingly.

    The diagnosis that “leadership” is the problem, is also dubious to me. It just looks a little unfair to me to ask others to implement your idea, and expect enthusiasm, when maybe, the idea is not that exciting after all. Maybe the author didn’t provide the leadership he is missing. (The article doesn’t mention what the SchoolTool was supposed to do.)

    See you

    Stephan

  21. Doug Leary says: (permalink)
    February 14th, 2006 at 7:18 pm

    Hi Mark,

    Thanks for taking the time to write up your thoughts here. I found your experiences with SchoolTool very instructive. I agree 100% that lack of effective leadership and management are major stumbling blocks to opensource dev. It’s nice to see somebody giving some serious thought to the problems of oss management instead of just writing them off as showstoppers. An idea that just came to me is that the large mass of older geeks nearing retirement age could be a tremendous resource.

    There are getting to be a lot of older geeks (geekzers?) who worked through the whole Personal Computing revolution and whose careers are now winding down. I’m 51 myself with 27yrs programming experience. A lot of us, while not Microsoft millionnaires or philanthropists, have enough financial security not to be worried about our own survival and are looking forward to having the free time to work on stuff just because it seems like a cool idea. Many have a good mixture of technical and management skills, and possibly are better adjusted than younger developers to the idea that you can’t always get your way, but the show must go on. Sounds to me like the ideal talent pool for opensource projects. Sort of like the Service Corps of Retired Executives, or a revved down version of the geek-squad folks who go set up networks in African villages and the like. I have no clue how to go about pitching such an idea to a group of people like that, but maybe you do.

  22. Pete says: (permalink)
    February 14th, 2006 at 7:28 pm

    One good thing to do is the Google 10%, where the core team can still have some fun time working on shiny toys. The shiny toys are often a waste of time, but often a huge timesaver.

  23. xd-greg says: (permalink)
    February 14th, 2006 at 7:41 pm

    Hello,

    I do not accept your argument as I see a fundamental flaw in your judgment of project development. What you propose is that open source developers are self-managing. That proposition is flawed at its core. In any situation, software development or space mission, there needs to be a clearly designed plan in order to achieve the ultimate goal. To place the blame for the failure of the project on open source development tactic is wrong. If you proceed to hire the best team of close(proprietary) source developers, and give them an ultimate goal without a plan they will inevitably fail as well.

    The case you have put forth should be titled the failure of project management, and not the misgivings about open source development cycle. I can guarantee you that if a leader was defined in your open source group he or she would manage to assign resources according to the goals at hand.

    Have a nice day,

    Greg

  24. Mike Lewis says: (permalink)
    February 14th, 2006 at 7:44 pm

    I once had the same problem with running a team of enthusiastic but somewhat naive programmers who got a little too interested in adding new features instead of making the core functionality work. I solved it by declaring we would develop two versions of the program at the same time: version one which would contain the core functionality or “must haves” and version two containing the “nice to haves”. I asked the developers to approach me before implementing a new idea so I could decide which version it would go into. I wanted them to keep coming to me with new ideas and not feel creatively stifled but I also wanted to get the basic product working and out the door. If I thought their idea belonged in version two, I made a careful note of it and let them see I was doing so but that’s as far as the development of version two went. What surprised me was that the whole team got into the spirit of the thing with shouts of “version two! version two!” echoing around the programming room when someone came up to me with one of the more radical ideas. Eventually, I didn’t have to decide which version a feature would go into – the team learned to decide for themselves. I just listened to the echoes.

    The system worked quite well. The team stayed enthusiastic about working there and the basic program got done in record time. The customers were quite satisfied with version one of the program and didn’t even want a version two. We also ended up with a list of features to put into the next version of the program if our competitors released a similar product.

  25. Chris Cunningham says: (permalink)
    February 14th, 2006 at 7:47 pm

    There was an old joke about a manager who hired the best programmer in town to write an accounting package for him. The programmer estimated it would take 9 months. Every month the manager and the programmer would meet in the hallway and the manager would ask the programmer how things were going with the standard reply being “good, we are on track”. About a month before the accounting package was supposed to go into production, the manager asked for more detail. The programmer replied “I’ve got the editor, compiler, and OS written. The database manager should be done this week and then I’ll start on the accounting package”….

  26. Tom Lord says: (permalink)
    February 14th, 2006 at 8:04 pm

    You simply don’t understand the word “philanthropist”, do you? (c.f. paragraph 1)

    -t

  27. Aigars Mahinovs says: (permalink)
    February 14th, 2006 at 8:13 pm

    The best thing in this particular case would be to get two to three IT managers of some schools across the world who work with the core team as customers. You should not be paying them, but covering travel expenses for a few face-to-face meetings would be a very good motivation for both the managers and the core team.

  28. AnonaMoose says: (permalink)
    February 14th, 2006 at 10:22 pm

    Howdy

    If the original team was using Java, why use XUL or the uber homegrown cross platform GUI framework when there is Swing ?

  29. Tim O'Brien says: (permalink)
    February 14th, 2006 at 10:24 pm

    The phenomena you are noticing has little to do with the “open source environment”. The lesson you learned isn’t even specific to computer programming. Hiring a group of people to do anything that requires collaboration and then failing to provide some coordinating influence leads to the same result as your first “experiment”.

  30. Tim Daly says: (permalink)
    February 14th, 2006 at 10:30 pm

    Some background and then my comment:

    Background: I’ve been writing code for 35 years and am the lead developer on 3 open source projects (axiom, magnus, doyencd).

    Comment : Hiring a “customer team” that is separate from the development team is a brilliant idea. Of course, the need for the
    customer team exists because you’re trying to use open source methods to deliver a focused product. I believe that you’ve made
    the “standard mistake” of assuming that you can use open source development to create products. I see it all the time and it won’t
    work, at least in my experience.

    The reason it fails is subtle but understandable. It’s the difference between hiring architects to
    design your house and hiring artists to design your house. The issue isn’t a difference in skill, knowledge, craftsmanship, experience,
    motivation, or talent. The difference is the goal. In both cases you will get “a house” but I’d bet that you won’t like the artist’s version
    of the house, at least if you allow the artist any leeway in conception. Both you and the artist understand the goal but the artist does
    what he does in order “to create” and therein lies the problem. Producing, or reproducing, a limited vision is not why we (at least, I)
    do open source.

    Axiom, for instance, is a computer algebra system. There are approximately 100 CA systems, of which about 95 are open source.
    What drives Axiom is that we’re trying to look beyond today and toward the 30 year horizon. What will we need in a computer
    algebra system 30 years from now? You can’t do this in product development because you won’t live to see the payback. But
    it attracts people who want to work on the hard problems (the shiny toys).

    Also you should be aware that the “bazaar” idea is nonsense, again in my experience. Virtually every “living” open source project
    has a “Linus” at the center. There is someone who is willing to do all the dogwork, the monthly updates, patch applications,
    regression testing, handholding, personality un-conflicting, etc. The idea that there are people who just wander into a project,
    contribute something and then dance away into the marketplace is foreign to every project that I’ve ever seen. The learning
    curve for any real project is very steep and the scope is usually much smaller than the linux, apache, mysql giants.

    As for funding (although apparently not an issue for you), forget about it. We have an “Axiom Foundation” which exists to
    manage funds. So far we’ve collected $500. (of which $100. of that is mine (I don’t have any involvement in the money))
    We did manage to get Google to fund a student for the Summer of Code which was another brilliant idea I hope they continue.
    In general, however, funding does not exist. This has an upside and a downside.

    Money ALWAYS has strings. ALWAYS. So a lack of funding means that we can pursue the dream without any issues being
    raised besides personal interest. That’s a major upside.

    The major downside is that I don’t believe open source can exist without somebody quietly funding it. With Axiom, for instance,
    I pay for a machine at a data center out of my personal funds, pay for the ISBN for the book, pay for the free copies of the
    book I give away, pay for my travel for the “invited speaker” opportunities, pay for the CDs, the bandwidth, etc. That is real
    dollars, not counting time costs.

    You’re of the belief that if you find some productive and qualified people, give them freedom from money issues, and suggest
    a clearly stated goal (“a house”) that you’ll get some magic benefit from doing open source style development. I believe that
    is unlikely. But I’m willing to be proven wrong.

    Tim Daly
    Axiom Lead Developer

  31. Les Brunswick says: (permalink)
    February 15th, 2006 at 12:14 am

    It seems to me that one way to solve this problem would be hire a group of programers who are already interesting in solving the problem the software is aimed at.

    So for instance, for an open source school administration program, hire some school IT people who have struggled with the propietary school administration programs that are out there. I bet such a group with be focused, motivated, and would come in already having a bunch of ideas about what the program should look like.

  32. Michael says: (permalink)
    February 15th, 2006 at 1:39 am

    One or more of your people should have not only time in as developers { with a heavy preference given to those with open source backgrounds} but also as small to medium sized non-profit directors and/or executives officiers. These people will have not only the technical background you need but should also have a greater understanding of the need to constantly move forward on the goals of the project.

    Furthemore a good NPO director{executive} often has to accept others’ visions and move forward with them while ensuring that the variuos volunteers, employees, contractors and clients are not only aware of the intent of the vision but also informed and enthused about the vision.

  33. Zak says: (permalink)
    February 15th, 2006 at 1:48 am

    Hi Mark

    I’d like to add a few disconnected thoughts here because this struck a chord with me – even though I’m reading it 2.5 years after the fact (thanks, Slashdot!)

    During work for one of my clients a few years back, I had a chance meeting with SchoolTool – this was very shortly before or after your space jaunt, Mark. I was tasked with getting it running for use in a school where we were to install an LTSP-based network for the pupils. I had the impression back then that it was developed using not-quite-appropriate tools (Java & MySQL (I think)) which in the case of the former presented both a challenge to deploy for a person not (ahem) schooled in the ways of Java as well as philosophical issues with regards to licensing, and in the case of the latter gave some concern for what pre-development criteria were used to determine the underlying software.

    At the time the overarching impression though was of a fantastically altruistic ideal being implemented by a team of good developers who seemed to lack some of the same idealistic resolve. I certainly hope the new ShoolTool can step into the breech – I do think that it is a good project, and I really do hope it will be a roaring success in its intended application.

    Cheers

    Zak

  34. Peter Fedorow says: (permalink)
    February 15th, 2006 at 2:24 am

    Unique projects, including software development is the creation of artwork.

    There are only three practical drives which cause one to produce works of art.
    1. Hunger
    2. Inspired discipline
    3. Passion for the work

    Any of those motivations will cause most people with the skill-set to produce the required work. Some motivations don’t work for some people, and some motivations produce better quality results than others.

    Hunger:
    A hunger for success, survival, or even just plain money, will motivate many people to create something which meets the requirements if they can, and if the motivation is structured too, will often produce the fastest results. However, at the same time, it usually also serves as a distraction from inspired creativity. Only an unusual few can actualize on inspiration when hungry, and usually only in very limited circumstances.

    Uninspired Discipline:
    Think the works of the street artist. Uninspired discipline is what produces the most volume, both in terms of 5 minute paintings, and successfully completed programming projects. Deconstructing problems is a high level function, that no matter how skilled one is, requires practised discipline to work through the periods that aren’t much fun.

    Passion For the Work:
    There is only one way to consistently surpass expectations. You need a cohesive team driven by passion for the task. For software development this means, you either need to find programmers with a passion for what’s being created, or you need a customer to work with programmers with one or more of these motivations, to complete the project. You’re in the best situation when you have both a customer, and a programmer who has a deep drive to get it right. Unfortunately, anytime you have a customer and a programmer work together, they usually do not know how to communicate. It’s caused by the customer not recognizing what they need until they see it, and the programmer not knowing how to, or wanting to, figure out what it is that the customer needs. Programmers excel at logical deconstruction and highly factual problem domains, not at getting into the mindset of others, and translating into requirements. That is where a project manager or product manager comes in. It is his or her responsibility to identify a customer who can work with the programmers, or programmers who can work with the customer, preferably both, and to facilitate the interaction.

    Regards,
    Peter Fedorow

  35. Allen Downey says: (permalink)
    February 15th, 2006 at 3:04 am

    It’s not enough to have vision. If you are designing for a user group (in this case school administrators), you have to go to the users. Get out of the lab!

    If the problem is that the team is “efficiently going down the wrong road”, how does having two teams help? Working with the users is the only way to find out what the right road is.

    Making the decision process open to “outsiders” doesn’t solve the problem either, unless the outsiders are potential users, not other programmers.

  36. vruz says: (permalink)
    February 15th, 2006 at 3:51 am

    sorry, but it seems slightly naive for me to think a group of programmers will self-assemble and produce something you haven’t specifically designed, planned and scheduled.

    it’s like expecting a football team to win the championship without a coach, or worse… a team of nurses to succesfully bringing back to life a patient after complicated surgery… without a Doctor !

    that’s precisely why the discipline of project management exists.
    really, it does exist in open source software too.

    in any case, looking for emergent behaviour in a team of programmers is an interesting experiment, but why does it sound like you’re like… whining ?

    another thing… your specific claim about the inability of “open source developers” in particular, are you absolutely certain a team composed of a different kind of developers would have shielded different results ?

    under this theory, why did Microsoft (a company with legions of good programmers, project managers and vast resources) choose to reimplement their own version of XUL called XAML ?
    are they an open source shop ? itch scratching ? does that make sense ?

    isn’t this more part of a set of very unreasonable expectations on your side ?

    maybe you didn’t understand the technology involved before jumping on board of that project ?

    really… I like what you do at Ubuntu and I’m very pleased of the many good things you’ve achieved and are striving for, and I’m sorry to say this post is one of the worst pieces of blogging related to software development I have ever read.

    worst ever.

  37. Jack Johnson says: (permalink)
    February 15th, 2006 at 4:06 am

    I’ve always thought the hinge that makes open source work is the drive to find a common solution to a shared problem. Programmer or end-user, you find yourself in a cul-de-sac (either vendor- or self-imposed), and you reach this point where the only one who can get you out is you.

    So you build something or borrow something and tweak it for your specific problem, and someone else says hey, I know how to make this crappy part better, someone else says I really need to implement this other feature to get out of my predicament, and it snowballs.

    The problem I see with contracted developers—especially for this project—is that it’s likely they’ve never been in the same jam as the end-users. You need to be two days away from graduation with transcripts fatally broken from a conceptual problem in the way scheduling was set up three years ago to really understand not only how things are broken but also how to address the problem through that lateral thinking you mentioned.

    Real problems usually get solved when you have your back against the wall and you have no other choice.

    To get your new team from following the old path, I would have them adopt a school, live in the trenches so the end-user problem is their problem. They need to know their work makes a difference, and share the pain when it doesn’t.

    Another excellent idea I’ve heard is to have them take a set of data they’re required to report and start building backwards, using that as a specification. Knowing what needs to be reported helps decide what needs to be collected, and the whole workflow should start to fall like dominoes. If you need an area of focus, pick the task that’s hardest, most painstaking, or most banal to do, the thing that the secretary, counselor or registrar tells you is the bane of their existence, and make it happen.

    Keep that geek toy from being shiny by wearing it out. :)

  38. Antoine van Gelder says: (permalink)
    February 15th, 2006 at 7:18 am

    If we assume that the necessary conditions of technical skills and sufficient funding exists there still exists one more condition for great software:

    The absolutely best software happens when the folk writing the software will be using it themselves, have strong emotional ties to someone who will be using it or if they are personally offended by the existence of problems that the software can alleviate or solve.

    Assuming that what I have written is true and I’m not just intellectualizing myself into a hole we suddenly find that although Open Source can go a long way to finding technical skill and reducing the cost we are sitting with the problem that very few software developers have spent enough time being exposed to (or have an interest in) problems beyond instant messaging, writing a cool theme engine or browsing the web.

    The easy answer for schooltool of course is to simply (hah!) find a lead developer who is both a superb coder and who has spent a lot of time developing insight into administration and a deep loathing of superflous beaurocracy.

    Difficult!

    But maybe there is a middle way – if you contracted one or more educators with an interest in computers (at least deputy headmaster level and perhaps another at teacher level) to participate in the project AND if there were sufficient chemistry between the development team and said educators there could be the potential for a team that could make a real difference.

    It would also be interesting to see what would happen if you tossed an archetypal frustrated high school software geek into the mix. :-)

    There are also the issue of problem solving and design methodologies such as TRIZ or Theory of Constraints but I have come to the belief that ultimately they are less important than the factors mentioned above.

    Open Source is difficult and from my fond memories of writing a timetable tool on a 6502 based Compukit UK101 back in Standard 5 I know that school administration is even more difficult.

    BUT

    I think Schooltool is absolutely tackling the most important problem facing educators today, so the best of luck!

    – antoine

  39. Jan Kuzník says: (permalink)
    February 15th, 2006 at 10:09 am

    Agreed. More people should be aware of this problem, because the situation is somethimes unbearable. For example recenty I was setting up a school computer class based on donated computers uncapable to run WinXP or GNOME well. OK XFce and Edubuntu seemed to be a good solution. Until the moment I realized they don’t have a usable FileManager (yet). Insted of fixing the existing one (Xffm4) they decided to make a new one from scratch (thunar). Their website provides really interresting reading how to design a filemanager. I would enjoy reading it in say 1994 but today eleven years after WIN95 such a discussion is crazy. I cannot expose my pupils to such a crap. Sorry, we have to go Microsoft once again.

  40. Hodgestar says: (permalink)
    February 15th, 2006 at 11:23 am

    Having read your entry, it struck me that part of the management problem might be the very concept of a development team. SchoolTool doesn’t strike me as a particularly ambitious project, but it does seem to lack focus and direction. The diffusion of responsibility that teams generate can only be a bad thing in such cases.

    I’d start any project with exactly one developer. Once they had something functional (even if barely so), I’d add new people to work on specific things. If things getting going a team of sorts would probably grow up around the project, but by then hopefully the project will have gathered momentum.

    The OSS development model focuses on individuals, especially when projects are small and starting out. The “itch” is not that important. What is important is that there be one developer, who sees a vision and has the strength of will and the ability to forge it in code. The job of the philanthropist is then to find that developer and make him or her see that vision.

  41. Eric S. Johansson says: (permalink)
    February 15th, 2006 at 6:11 pm

    I’m really glad to see someone addressing the issue of open source project management. This discipline is necessary even if there is a single developer. When I’ve been project lead on a group project (IPCop), I tried really hard to keep people focused on the right things at the right time. It was difficult however to implement proper testing procedures because I’m a believer in many releases with small changes between them. This process is very useful for detecting which features/bug fixes caused new problems. Unfortunately, this is pretty annoying to open source dilettante’s because they can’t or don’t understand the necessity for testing procedures.

    In my own open source single developer projects (camram antispam, akasha small-scale web development environment), Project discipline is just as important because you can’t make radical changes and expect to get anything done because of limited resources (i.e. just yourself). For example, I can see how Akasha would simplify the camram web interface but I’m not going to make the change until that’s the only change.

    keep at it. It’s the right thing to do and developers need to learn that open source doesn’t mean unlimited right to chase bright shiny objects.

  42. Ian Woollard says: (permalink)
    February 15th, 2006 at 7:15 pm

    Doh! This wasn’t a problem with open source software, it was problem with how you decided to pay for things. You don’t develop software (open source or not) on a cost-plus basis, you do it with clear milestones, associated with payment at each successful step.

    Anything else is madness.

  43. Kevin says: (permalink)
    February 15th, 2006 at 8:19 pm

    A classic example of Software Project Failure tendency #1:

    “If product management does not manage the programmers, they will not produce a product.
    They will produced a lifestyle.”

  44. Brandon Zylstra says: (permalink)
    February 15th, 2006 at 10:40 pm

    Have you considered using Agile development methods? For instance, with XP (just one of many Agile methodologies), your developers would meet regularly with you (the customer) showing you their work and getting feedback and direction from you at a high level.

    Because developers are (necessarily!) working at a much lower level, they can easily get tied down in details, and can easily get sidetracked by solving problems related to those details, problems that will make their life easier (a la XUL: I’m sure it made many aspects of developing Mozilla vastly simpler). Developers left to their own devices will begin solving *their own* problems, rather than their customers’ problems.

  45. Gerhard Jansen van Vuuren says: (permalink)
    February 19th, 2006 at 3:39 am

    Hi Mark,

    As a fellow South African I see you as a symbol of hope and truth in that anything is possible. I myself am currently a developer in mostly the old Windows environment, but I come from a self taught background. The software world was mostly appealing to me and still is because I can see many of my ideas realised without massive amounts of time and money that I don’t have. Where I have always been a very creative person so writhing/creating an online image editor seems more in my grasp that building a radar dimensional camera. Although I would love the build my camera since it will transform computer image recognition and processing I believe.

    But back to your problem of sidetracking, I mostly work for myself so my projects are to solve other people’s problems. I can live with that it pays the bills. But now and again I can get totally carried away with a new idea or technology and then I have to remind myself of the goals I need to achieve or I might not get paid. It takes a lot of discipline to get the job done. When I was employed I had similar problems so you could argue that it is the creative and inquisitive nature of man that leads to these sidetracking sprees. Also I have found that working on the same project sometimes becomes a bit cumbersome and boring. So having something else to get sidetracked on is almost an escape mechanism.

    So I have found what I have to do occasionally is step away from the development work and clear the old mind by finding motivation and inspiration for the project again. Now what works for me is talking about it. Almost brainstorming but more focused on what is left to do and what has been done and how this will help whom ever it should help but try to stay away from talking about new ideas. This will only encourage that creating new things thing. So I suppose ultimately you need a person with strong skills in development, people and management with a level head and that understands the goal of the project and wants it realised. That is willing to let a version one go and can put all that other fancy stuff not required right now in the ideas box and for future version.

  46. Stephan Deibel says: (permalink)
    February 26th, 2006 at 8:32 pm

    Interesting to read this more carefully than I did when I saw it (on slashdot, I think). My initial impression from a late-night scanning w/o really reading was that the current SchoolTool project was canceled and it was “confirmed” multiple times by talking to people here at PyCon.

    Well, I’m very glad to hear it’s not canceled! But be aware there may be some confusion from others that skimmed the article as irresponsibly as I did!

  47. rakesh says: (permalink)
    March 12th, 2006 at 4:24 pm

    I have to make project in MCA in application development or web development.Please help me.

  48. Nathan M. Willard says: (permalink)
    March 30th, 2006 at 2:55 am

    I would have to agree greatly with what you said it is important to get the core product out the door ofcourse it is vital to encourage “geektoys” it is those innovations that will excelerate open source faster then poprietary.

    I noticed you dont get that many post’s on here so I wouldnt know if you read them or not but either way I just want to say what you are doing for humanity is a great thing, it is too bad that there is not more people who have the means to change the world and to do it for the better.

  49. Ray Wright says: (permalink)
    April 20th, 2006 at 8:42 pm

    Hi Mark,

    Its great what you’ve done to create an awareness and interest in Space travel. What are your thoughts on Elon Musk, and SpaceX? Would you ever consider such a project? What would you consider to be the next great step for mankind to take?
    Keep up the good work, and all the best,
    Ray

  50. rootbeer says: (permalink)
    May 9th, 2006 at 4:09 pm

    Quite honestly. Here is my 10.5 cents of opinion on this. For ME to ever even begin to think about joining a group in the long term. VISION is the only thing. To look at teams of developers to filfull your vision is selfish. Are we not allowed to have our own vision? Do we have to follow the vision of the people that have money. Are they empowered with the ability to envisage the world? I will never again word for a place, institution or individual that feels their vision is the the that must be fulfilled. In reverse if I feel the same when empowered with resources then I am a charlatan. Quite frankly, I hope I never find out. I’d rather sit here on the West Rand and try fulfill my own visions and one day, hopefully realize that OUR visions are more important. I had to share this altough I have no place to in this little fortunately changing world. is it greater vision or is it still the vision of the “greater minds”. While that is so, the world will not change. I cannot even express how I feel about this except to say that, as a layman, I will word for the man whose Vision I share first before I submit to some ungodly project where bonuses are paid – no matter how much I lose in the process. This describes about 20% of what I really feel about this and apologize for now knowing what it feels like to have that form of power to implement my own visions.

  51. Robert Schumann says: (permalink)
    May 22nd, 2006 at 10:57 pm

    I recently attended a conference on “Sustainability in open source software” organised primarily for the higher education sector. Three major things struck me, and I’ll mention them in decreaing order of relevance ;-)

    1. Some public health IT developers were in attendance, and I learnt about WorldVista (http://worldvista.org/) which is an electronic patient record system deployed by the US Veterans’ Administration (about 1300 facilities, a few million patients on the books). Their software is revered by the users – a rare phenomenon in public IT projects! – and was developed in an open source way before open source existed (the project started in 1975, IIRC). I’m curious to find out more, and see how the project was managed into success.

    2. The education sector people were continuously facing the paradox: How do you financially sustain a software project that you hope becomes self-sustaining? The problem is particularly acute in the public sector, where decisions are sometimes made for very strange reasons. Not only that, the natural, organic, user-driven development process found in OSS development is replaced with central planning and overly-large budgets. I think Canonical/Ubuntu would be the first to admit that open source is typically not about planning but about harnessing a rather chaotic set of self-driven projects.

    3. My impression is that we know how open source works in the organic, itch-to-scratch model; we know how it works in the high-rolling, big-iron, support and customization model of IBM and Red Hat; we even know how it works in the closed-to-open route, as exemplified by TurboCash, which improves the quality and user base of the software; but we don’t know how it works in the centrally-planned and paid-for model.

    Well, I don’t.

  52. Adriaan Etsebeth says: (permalink)
    August 29th, 2006 at 1:29 pm

    Hi Mark, I hope you read this at some point. I am a facilitator / project leader at Wits, with an idea which can influence our whole economy.. ‘serious’ as they say. Have been working on this a while – 4 years to be more accurate. I need someone with vision; and as you said in Schooltool – not everyone have an understanding.. Could you hear me out? Not on the net though.. Greetings Adriaan

  53. Jonah says: (permalink)
    November 9th, 2006 at 5:11 am

    Hi Mark,

    I know this is an old thread, but I refer to it often and it makes a great anecdote.

    I just returned from PloneCon, where I had been thinking alot about hybrid economies and how they shape that particular project (especially compared to the likes of Sakai, or even Moodle).

    Honest Software

    I think I might have conflated a few different ideas here, but it still kinda holds together.

    Tough to imagine designing a project so that it participated in this many economies, but that could be a part of making these projects succeed.

    cheers,
    /Jonah

  54. Ernst vd Merwe says: (permalink)
    January 14th, 2007 at 8:15 pm

    I have heard about the probability to get support. I have investigated investments markets, money, business and production cycles since 1992. I have researched the facilities available to bank clients worldwide. I have analize the role of bond originators,banks and the impact of interest and tax on the very famous ratio interest and principal amounts. After finishing my masters degree in economics I have also carefully research exhange rates and inflation with the idea to formulate impact. I had also try to minimise risk by having that included in my ideas. I have manage to enable myself with to master Visual Basic Programming. Here I have tried to intensify my knowlegde on objects. Basically the outcome make me realize that especially objects are entrenched by Microsoft in their effort to make money. I believe that moving back to “machine language” restrictions because of versions of objects can be breached. I have concentrated a great deal on multidimensional arrays, .dat files etc in persuing my dream of having an integrative calculating program in supporting best decisions referring to financial schedules. A program has been written by me to +- 90 completion. I want to make it available to people who intent to buy property or business. My idea is have it available on the internet.

    Where, who and when can I make a presentation to, to unlock gold!

    Your help will be of uncalculatable worth!

  55. Sheldon Smuts says: (permalink)
    January 27th, 2007 at 2:17 pm

    I am semi computer illiterate and heard that you have a anti virus programme for people like me.
    We tried Norton and find that besides wasting our money, it is impossible to operate.
    Can you advise
    Thanks

    Sheldon

  56. edward meyer says: (permalink)
    March 7th, 2007 at 10:49 am

    i started a shower door company with 15 years experience in the industry. my company has been awarded some big projects and this has affected my cash flow i dont know where to turn to, can someone please help OH YES I did mark’s mom’s house in d’ville.

    Regards
    Eddy Meyer
    0725015501

  57. hendrik says: (permalink)
    April 13th, 2007 at 7:20 pm

    Hi Mark ,
    We have a brilliant idea that has nothing to do with pc`s and internet but rather an unique method of selling properties internally, but we need funding to kick start it.

    Can you assist us here we do not talk big amounts,
    If you interested please come back to us

    Hendrik bluegloo.com

  58. Zelda says: (permalink)
    July 7th, 2007 at 7:24 am

    Myself and two partners started a company a year ago. It started as a hobby on the side line based on our passions for the mining industry… What a mistake!!! It has spiraled out of control!!!

    Currently we are developing software for the mining industry. The project we are busy with has been validated for R110,000,000.00… I again say: myself and two partners… We do not have the resources. We have the clients. We have the market. We have the software. We have orders. But, ourselves cannot do this, as this is our hobby and we love our jobs!!! We do not know what to do…

    At this stage we are praying that something will happen and a mining house will turn around and buy the entire package – even if we are only offered R30,000,000.00. Sounds desperate – we are!!!

    Can you assist us with guidance? I know the logical solution will be to quit our current jobs – we are all high earners – and go for this project full on, but then we have to appoint IT personnel. Money is not a problem. I do not like this idea however, as we are desperate and in desperate times one do not think clearly and I am scared we will appoint incompotent people. I have investigated the salary scale for the IT skills we require and decided if we take this route, we will go into the recruitment market above the scale to pull in the best, but we wary…

    What should we do??? Should we go for the option of R30,000,000.00, cut our losses and move to the next two projects we have lined up or should we go for this project and run all three together with a company of 50 people?

    This is not our first project. Our first project we handed to another engineering company for FREE on a silver platter yesterday afternoon – estimated value of R40,000,000.00. We do not have the resources… This was the only option as our current project is taking up all our free time and we were scared of losing face in the industry – we have already made a name for ourselves.

    Company name:
    the visual component

    Company partners:
    Metallurgical Engineer (Business Risk Management Consultant),
    Attorney (Business Legal Liability Consultant),
    ex Mine Inspector (Mining Production and Safety Behaviour Expert)

    Company scope:
    Legal risk management
    We look at legal aspects in the mining industry. Aspects where behaviour turns the legal aspect into a HIGH risk. Knowing risk management, it will be best to terminate the risk than to tolerate or treat it. This however is not always possible as the risk arise from a legal aspect – thus it is law. The safety behaviour can be addressed, but in South Africa we have been mining for so long and behaviour changes is not always easy and/or effective – we have a culture of production and not safety… We develop software that “basically” addresses these legal aspects by controlling the behaviour risks – thus, we terminate the risks and enhance safety behaviour…

    As you should know, Anglo Platinum closed 5 of their shafts a couple of weeks ago to address these safety behaviour issues – they retrained all their employees and lost R750.00 PER SECOND in production. This was a drastical step and noted internationally!!! Needless to say they are one of our biggest clients…

    We need help!!!

    Managing Director

  59. Paul H Roux says: (permalink)
    September 18th, 2007 at 11:07 am

    Hi Mark

    I have sold my house in Parow North and then decided to buy another one that needed attention also in Parow North for R1 000 000.00 through the bank. I started renovating the house and have got about 70% complete. Unfortunately my funds have run out as I have used my profit of R700 000.00 of the house I sold and now I stand to lose everthing I own and worked for if I do not get an investor of some sort to help me out. My intention for the renovated house was to turn it into a guest house as I have planned it so to have 15 bedrooms with en-suites and a extra bathroom with a spa bath, toilet and shower already installed. The house is entirely designed by myself with each bedroom and room done with fond memories of old and new. My business books are also behind and have to be updated for the last four years.I also need advice and help on that. Is there any chance that you know of someone looking to invest in this type of venture to help me out on saving my exciting and profitable venture. The guest house would be especially good for 2010. I know this has nothing to do with pc’s and the internet but I really need help in making this venture work and have already got so far. It would be such shame to see this all fall through the mat. Please see if you could assist me. I am available on Cell: 082 6121 983 or Tel: 021 9304040. Thanking you. Regards P H Roux

  60. Jack says: (permalink)
    September 19th, 2007 at 10:33 pm

    So, Mark: it’s four years down the road. Did your new team organization keep the project on track? Did you need additional innovations?

    Is this http://www.schooltool.org? That project looks to have achieved core functionality, and on-going M&E seems pretty healthy, judging by ohloh.

  61. Boris says: (permalink)
    September 22nd, 2007 at 8:52 am

    We would like to get hold of Mark Shuttleworth with regards to the tranport project that was published in the newspaper yesterday – we have been involved in this for the past 5 years and have great vision for the business but have not been able to get the finance – please can we send our business plan for perusal.
    Thanks very much,
    Boris Miller and Rob Louw

  62. John Peterson says: (permalink)
    October 20th, 2007 at 1:29 am

    Projects are like snowballs, you’ve got to pack a snowball and then roll it manually for a bit before it has the mass to roll itself. Like with a snowball, you should start out small, as trying to pack an armful of snow together is pretty futile. Get two bright minds together and get some cohesion there before trying to add more to the team. I’d suggest that this initial team be made up of one potential customer and one developer. If you want to accelerate the process, pack a bunch of competing “snowballs” at once and see how each evolves. You can then pick and choose ideas from each team. Never underestimate the power of competition in a demographic of individuals with egos the size of Texas.

    You can’t really expect much real code to be written in the beginning. A certain amount of time needs to be spent in idea generation, but once a base feature set is agreed upon, you can move into the development stage. It is here that your “cats” will usually run wild, because they will still be in brainstorming mode. Here are a few ideas for keeping your “cats” not only moving, but moving in the right direction.

    Divide your list of desired features into two sets (version 1 and 2 as Mike Lewis suggested above). This will for the most part keep your developers grounded. During development, if a developer comes up with a bright idea, you make the decision about the importance of the feature by assigning it to a version. Just like a box of apples, we humans have a tendency to go for the shiniest ones first. It’s not until you limit a developer’s options to the less desirable ones that they will get to the dirty work. Keeping the possibility open for a version 2 keeps developers motivated, because they have hopes of pushing through version 1 and getting to the shiny apples in version 2. Not that there won’t be shiny apples in version 1, but the shiniest will be consumed first and what’s left is usually the majority of the work.

    When the shiny ones are all gone and you’re down to the less interesting features, the developers may have a hard time staying motivated. As Barry Schwartz states, “with so many options to choose from, people find it difficult to choose at all”. As the leader, it is your role to make the hard decisions; to reduce options and free your developers up from this paralysis of indecision. Make a priority list and review and revise it frequently.

    There is one thing that developers absolutely thrive on: Feedback. There is nothing they enjoy more than getting to show off what they’ve accomplished. Every week or two, check in with your developers and have them provide you with an overview of their progress (or lack thereof). Ideally, they should provide a daily status report (via an email or a blog posting), so that you can rescue them early on from any ruts they may have fallen into.

    As a developer, there is one more underlying motivation that drives me on. I want whatever I develop to be used. The more people it can potentially be used by and the more they may use it, the better. It is for this reason that I find user interface development (especially on the desktop) to be the most exciting area in the field of computing, because it really does cater to the largest audience out there.

  63. OSS project management: Divide and Conquer? | RTFM says: (permalink)
    August 21st, 2011 at 2:50 am

    [...] Shuttleworth is testing an interesting theory of project managment. He’s divided a development effort between two individual teams in hopes [...]