Open letter to an Apache mailing list regarding their OpenOffice incubation plan. This was originally written in June 2011, so is out of date but much still applies.

Having written code in Microsoft Office, why this Apache fork is bad is intuitively obvious to me. I wish everyone had the same instincts. In the days since I first saw the announcements, I’ve been reading and learning a number of additional facts that helped me understand all the reasons why for this situation.

Here I will summarize the “no” vote reasons against this Apache incubation proposal. While reading, I gained respect for the Apache foundation and the OpenOffice brand. There is love people attach to these names. Apache could offer poop on a stick and it would have downloads and people curious about how to make it better.

Many of us want all of these good ideas and energies to be channeled. The LibreOffice team is not a raging success yet and they’ve just climbed some big hills. Yet no one inside is complaining of a reason to fork.

Given all I have read, this is my (unfinished) list for the arguments against:
——-

1. This is mostly a code dump, not the set of 50(?) full-time engineers who have created / been maintaining this code.
2. This technology is massive. It is about the same size as the Linux kernel (10 million lines). This is a world that thousands could get lost in. Because the codebase is so large, it makes the cost of the fork that much greater.
3. IBM’s priority will be on Symphony and Notes (which build on top) more than the core code.
4. Much of the expertise is at Sun / Oracle, and IBM is not bringing many of them over.
5. IBM’s biggest investment here is “open source” evangelists. They believe the community will build everything for them.
6. This is mostly a cabal of IBM / Sun evangelists trying to confuse Apache into letting them fork the LibreOffice community.
7. The Apache foundation has a lot of experience, but none with this technology. Therefore, their help will be limited. It is like asking a hospital to fix your car.
8. The Apache foundation requires developers use SVN, which is not as good as Git for handling a large distributed project.
9. The code dump is missing a lot (filters, images, translations, etc.)
10. OpenOffice is now primarily a brand to be preserved.
11. This brand is in jeopardy now.
12. There is nothing to incubate. LibreOffice has just built everything you need.
13. The Apache License (AL2) is not within the spirit of the tradition of this codebase.
14. There is no company waiting to build some amazing technology like Watson in LibreOffice but hold back because of its “restrictive” license. These are just fantasies IBM can promise and a rhetorical trick because anything about the future is impossible to disprove.
15. A proprietary Watson could be built on LO today. LGPL is the ideal license for this codebase, a compromise between GPL and Apache. LibreOffice should not compromise anymore.
16. This proposal is considered to have a practical license agreement, but grabbing code changes from LibreOffice is said to be impractical. This is not considered a problem.
17. Linus said that making Linux the GPL was the “best thing he ever did.”
18. Copyleft is compelling to small LibreOffice contributors. “Do you really want to write Apache 2 (AL2) so that IBM can make it proprietary and sell it?”
19. The move from Java towards Python in LO will add more barriers.
20. There is a lot to be done: polish, services, plugins, mobile, etc. We don’t have people to waste.
21. LO has just recruited many of the most passionate and experienced volunteers and other unaffiliated third-parties.
22. People will show up here because of the Apache, OpenOffice, and IBM name. They will not understand what is going on.
23. There were 87 contributors who signed on to this proposal, but many are just curious.
24. The leaders create bad plans, find curious and naive people who “support” it, and use those numbers as proof that their plan has merit and should go forward.
25. The community of contributors to this podling is artificially inflated with “advocates” and not many people with expertise in the OO codebase.
26. Microsoft would root for Apache to fork the LibreOffice community.
27. LibreOffice is a young community, so some are easily confused and frightened. Many barely know this name “LibreOffice”. Meanwhile LO needs and would love to have more people.
28. The OO brand was given up by Oracle primarily because of the success of LibreOffice.
29. The OpenOffice brand would be very valuable to LO today.
30. These “open source” evangelists from IBM, Sun, etc. should hand over the OpenOffice trademark before they hurt someone. LibreOffice can maximize the value and carry it on best right now.
31. They need all kinds of help. They are not turning down one contribution, and no one inside is threatening to fork because of problems.
32. The hardware / bandwidth costs are not very expensive. It is the human costs.
33. It is not just a question of if you fail, but what is the damage in that failed experiment.
34. There is also the opportunity cost of doing something better than failure.
35. Rather than using resources to help LibreOffice, they are used to hurt them, and waste their own life rebuilding what LibreOffice has just finished.
36. If this podling fails, it could hurt the value of the OpenOffice brand, LibreOffice, waste resources (these emails are just the start), hurt Apache’s reputation, etc.
37. Forks are one of the biggest reasons why free software has struggled in places. For an example in another industry, look at Blu-Ray vs. HD-DVD.
38. People at IBM responsible for Notes / Symphony may get bad reviews for building on top of a dying fork and when internal customers complain the product isn’t as good as what comes with Linux. These “open source” evangelists are supposed to have their finger on the pulse of the community, not their finger in the face of the community. I stole that from someone 😉
39. No major revisions have been proposed.
40. A “no” vote on current idea is fail-fast and the potential for a better plan.
41. LO see this as a danger. They received more cash donations since this announcement.
42. It will only be a trickle of volunteers. If more show up, LibreOffice can recruit in bulk.
43. With the interested people already occupied, this will never catch up with LibreOffice.
44. Wise people I have consulted with in LibreOffice believe this will fail.
45. Some are not even worried anymore, but I am less confident.
46. Some believe the Apache foundation is being used to legitimize a premature idea.
47. I believe the result will be the same no matter the vote unless the plan is changed. This plan is like an animal chewing off its own paw even though it wasn’t stuck in a trap.
48. Once you have written failure into your plans, like to build a house out of sand instead of concrete, these “friendly” meetings to resolve differences cannot achieve much.
49. May, 2012: IBM has made their proprietary Symphony code available for free. Initially, many thought that the primary reason IBM wanted this project in the Apache foundations was because because they wanted to build a proprietary Symphony on top, and only the lax Apache license allowed for this. So now that the their proprietary code is free, even this reason disappears.

———

I am an un-affiliated observer rooting for Linux on the desktop and Python over Java. I have spent years surveying and writing about Linux so I’ve come to respect the Apache server very much. Any rude bits in my mails were directed at IBM 😉 I believe they should know better than to attempt to fork a community. I think the Apache foundation has been caught in the cross-fire of the language and license battles. I feel sorry for these political battles. There are also actual proprietary competitors to fight as well! Isn’t that the most important?

Even if this is born, and fails, the community will pick up the pieces. It has many times before. The LO opinion of the plan is close to unanimous and strongly-felt. My feelings are more mixed.

Perhaps this can help serve as impetus for the vote. Many are curious to its result and are anxiously awaiting.

Hope this work is helpful.

Warm regards,

-Keith

Update: June 13: The podling was created. Oh well, Rome wasn’t built in a day. It is tragic that they’ve designed failure into their plans. Not only that, the opportunity cost of combining resources immediately. Reading their plan, some sentences are reasonable, and some stand out like daggers.

A better plan would have helped instead of hurt. These emails were a huge waste of time, and just the start. Many “open source” evangelists are actually hindrances. Some think forks are okay because they’ve happened before. This is like advocating for slavery because slavery has happened before.

The worst part is that the supporters of this plan made no changes to address the major flaws found by the community since the proposal was first announced. It is rude not to retract and make a new plan when relevant people have big objections to your idea. If you want to get code into the Linux kernel, you need to fix all the problems people find. Plans can be refined and improved, but this did not happen. The cost of the flaws only gets more expensive as this goes forward. Therefore, it was cheapest to vote this down now, so we can make a new plan. The new plan would involve something like making LibreOffice and its license the mainline, and merging TDF and Apache. Who knows where it goes from here.

Post is here.

Start:

I wrote two responses, which eventually allowed me to boil it down to
one sentence: You can do anything you want in addition to perfection
(i.e. zero bugs).
Long answer:

I was baptized into the zero bugs religion about 20 years ago. This
was before the web and time-based releases, but these only add
complications, and are yet compatible with zero bugs all the time. As
a beginner, you can cheat such as zero bugs older than 6 months / 2
releases, or give yourself 1,000. Over time, you can pick new goals
and improve your numbers. Reaching enlightenment may require multiple
steps. You don't have to meet your goals, but you will become better
for trying.

Original link here.

Copied here:

Many interesting ideas on version numbering schemes. I like 2.11.X because it maps to years easily in people’s mind, but I look forward to seeing what is chosen. You guys break many of the rules for software development, so why not going backwards in version numbers 😉

While you are talking about arbitrary numbers and new goals, I want to offer that you could consider a push towards zero bugs. In general, as long as your reliability monotonically increases (no regressions) that is an acceptable minimum approach because it means that you will never have a customer go from being happy to unhappy.

However, it is common in companies to make an effort to get towards zero bugs. Zero bugs is impossible, and that is a philosophical discussion. If you look through your current list of bugs, nearly every one looks scary to me and important to someone. You currently have 2,800 active bugs (http://bit.ly/LinuxBugs) The last time I looked, I found the median age was 10 months. In general, bugs should be fixed in the next release and so therefore 3 months.

Zero bug bounces is hard for the others because they don’t have sufficient resources. However, I believe you easily do. I can’t say that anything magical technically will happen if you work on your bugs faster, but I can say that people I respect as much as you taught me this. My salary was based on my ability to promptly respond to my bugs, and zero was everyone’s goal. Hitting zero, even for a minute, could be a newsworthy event, as another way Linux is better than the others. It also shows leadership to user mode. I sometimes get the feeling that many in the FOSS community look at bugs as something they could work on when they get bored of adding new features, instead of: “Holy poop, there is someone unhappy out there.”

Warm regards,

-Keith
http://keithcu.com/

I have decided to restart OpenRacing: (Note, we may rename it to PyTorcs or pySpeed-Dreams[1]) Note, I’ve decided to call it PyTorcs for now. See you in Github.

PyTorcs is based on the Torcs codebase, which is widely considered the best FOSS racing game and which already has autonomous cars. However, the codebase contains a lot of cruft.

So, it has been methodically re-written into C# Python, ported to leverage the graphics engine Ogre, the physics engine ODE, OIS, standard widget APIs, OpenAL, and extended with a more general track model.

Then, there will be a clean and 6x smaller codebase, with the heritage of Torcs, for simulating autonomous vehicles which can handle the complexities of urban scenarios, and can eventually navigate via the use of a vision recognition engine and simulated sensors like radar and GPS.

There is nothing to announce yet but a plan. Here it is so far:

Python Port

1. Do mechanical port of C# code (http://codeconverter.sharpdevelop.net/SnippetConverter.aspx)
2. Port the Swig wrapping tools to generate Python
3. Debug

Steps after which can go independently:

• Extra data attached to map model
• Define map APIs for the robots to use. ([[1]], [[2]],[[3]]) In the short term, it seems will need three spatial indices inside the map, physics, and graphics engines.
• Get basic autocar driving (waypoints, lanes)
• Grab more features from [Simplix]
• Networking
• Windows & Mac port (remaining code is very portable)
• Make map more pleasant to look at.
• Simulate Lidar (Can we put the source of light behind the camera?)
• Faster than realtime simulation runs (turn off graphics, optimize physics)
• Better weather
• Port over a new and prettier car model from Speed-Dreams and discuss the current set of difficulties in using their data with Ogre
• Find / modify a big urban map with highway exit
• OpenStreetMap augmented-reality visual annotations
• OpenStreetMap auto-generate mesh to drive through
• Smart objects like street lights
• Assisted-driving features (prevent crashes)
• Port over automatic transmission, wheels, etc. from Torcs / Speed-Dreams
• Plug into vision engine
• Define, record, and replay simulations
• Joystick, better keyboard
• Port simuv3 to Python (low priority, isolated task)
• Etc.

If you are interested in working in a Python driving simulator, please contact me or put in some information below. There are plenty of big and little tasks. A handful of people, let alone 10, could accomplish a lot, chipping away in any of those areas. I’ll make another post here when the Github repository is ready, C# is gone (Github here) Python is running.

[1] Just kidding about the last one. I am looking for a good readable simple name, but I never got to choose names of the codebases I worked on so I’m not practiced at it.

This is a rant I posted to the Ableton forum.

Open letter to Ableton;

I was very annoyed about Ableton / Linux support, so I decided to come here and complain and I found a thread — of course!

If an application supports Windows and Mac, supporting Linux is not much work. Somehow, there are very many products that work on all 3 platforms. If you only supported Windows, you would be in much worse shape. I’ll bet a sandwich Ableton doesn’t have even have one person working on Linux. 3-5 could have a solid native port in a few months.

The Linux audio stack is getting mature now. What is required now is a realization by you that your customers want Linux support. Note, the WINE support for Ableton Live is getting solid today, but it does have problems. On the latest Ubuntu, it installs and runs, which is a big milestone, but it has some perf glitches (some things are very slow), and the audio doesn’t work. With Ableton supporting Linux directly, or via Wine, ideally both, these problems could easily and quickly get fixed.

A free / GPL Ableton would be very nice, but the proprietary version of Ableton on Linux enables users to run a free OS, which is even better. Not supporting Linux is damaging to the freedom of Ableton’s customers. Microsoft continues to win because of the lack of vision or laziness of others.

I don’t recommend rioting in the streets, but I do encourage customers to loudly remind every software vendor that the freedom to choose your own OS is very important, and companies should respect their customers’ hardware and software preferences.

You might think it isn’t worth it to build a Linux version today, but how can you know the demand of a product you don’t have? Linux marketshare is growing every year and studies show that worldwide usage is comparable to the Macintosh today. It is true that not much music-making is done on Linux now, but that is partially your fault! Are you waiting for Linux to be dominant in music-making before you enter the market? Any businessman will tell you that is exactly backwards.

People may not use a product if it doesn’t run on all platforms: PDF, Flash, Firefox, Wikipedia, etc., etc. are popular because they work on all platforms. Not having a Linux version puts the entire company at risk.

I know you are busy, but that you can afford it. It is not a matter of development being at capacity (as if people ever sit around), it is a matter of prioritizing. When you say you don’t have the resources, you just are saying it doesn’t seem important yet. You actually could make a major shift in priorities quickly if you wanted to. Requirements often show up up mid-way through every development cycle that need to be incorporated, and it gets done. Ableton says that they aren’t going to support Linux because they can’t be “all things to all people”. That is equating one feature with all features.

You either embrace the future or your competitors do it for you. I don’t care who builds it, but music-making software is one of the top challenges for the Linux desktop. Many people run 1 or 2 proprietary apps on Linux. Several of Ableton’s employees are long-time users of Debian Linux. It is sad that Linux has so many users who are not supporters. Supporting Linux can mean many things, I just ask you to start with creating a version of Ableton that runs on at least Debian. If you feel very busy, I can recommend moving away from C++ towards 99% Python. That will help help speed the Linux port and every other feature.

Regards,

-Keith
http://keithcu.com/SoftwareWars/

P.S. Here is a quote:

Sometimes the real hurdle to renewal is not a lack of options, but a lack of flexibility in resource allocation. All too often, legacy projects get richly funded year after year while new initiatives go begging. This, more than anything, is why companies regularly forfeit the future — they over invest in “what is” at the expense of “what could be.”

New projects are deemed “untested”, “risky”, or a “diversion of resources.” Thus while senior execs may happily fund a billion-dollar acquisition, someone a few levels down who attempts to “borrow” a half-dozen talented individuals for a new project, or carve a few thousand dollars out of a legacy budget, is likely to find the task on par with a dental extraction.

The resource allocation model is typically biased against new ideas, since it demands a level of certainty about volumes, costs, timelines, and profits that simply can’t be satisfied when an ideal is truly novel. While it’s easy to predict the returns on a project that is a linear extension of an existing business, the payback on an unconventional idea will be harder to calculate.

Managers running established businesses seldom have to defend the strategic risk they take when they pour good money into a slowly decaying business model, or overfund an activity that is already producing diminishing returns.

How do you accelerate the redeployment of resources from legacy programs to future-focused initiatives?

—Gary Hamel, The Future of Management