What open source could learn from proprietary platforms
Open source has proved to be phenomenally successful, and continues to grow. As open source grows beyond its roots in software infrastructure like operating systems and Web servers, however, it is finding that the types of community it attracts is increasingly corporate.
Even in the geeky application server layer, Marc Fleury notes that JBoss' "community meant users, partners, consultants," not the freedom-loving developers we often associate with open source. This is because our simplistic conception of community has likely always been wrong, as Michael Dehaan suggests.
Open source has long been more about users than developers for the simple fact that a far greater number of people know how to use software than develop it. Hence, though Richard Stallman and early proponents of open source have issued a clarion call for the developer's right to view and modify source code, the silent majority of the open-source community really only cares about the right to use and extend binary code.
So, you see Openbravo's Paolo Juvara suggesting to its open-source enterprise resource planning community that it might be advisable to extend the Openbravo system, rather than customize it. (Read: modify core source code.) Or you read Jake Goldman rightly arguing that open-source software can lead to closed platforms (e.g., if APIs are not well-documented), while proprietary platforms like Mac OS X or Salesforce.com can actually be much more open platforms, despite keeping source code closed.
In an ideal world, you'd have open source and open platforms, but not every open-source project lives up to that ideal. It's therefore not surprising that open source is growing in two different but aligned directions.
The first direction is commercial open source, which generally trades off the promise of 100 percent source-code access for a hybrid open/proprietary approach, as The 451 Group captures in a recent blog post. This is spawned by a need to frontload development with a paid community at a level of the software stack that doesn't attract a broad development community. (How many people do you know have the aptitude and interest to develop an open-source customer relationship management system? Exactly.)
The second direction is proprietary software that emulates the best of open source by keeping APIs, data, etc. open. This comprises Web 2.0 and other technologies that are open, but not necessarily in a way that would pass muster with the Open Source Initiative.
Both approaches involve openness. Both make trade-offs, and this isn't necessarily a bad thing. Jake Goldman, echoing Tim O'Reilly's suggestion that open-source licensing matters very little in the grand scheme of things, declares "it's all about platform openness and adoption, not base code openness." He's absolutely correct.
Open-source projects need to focus on more than their license. We need to improve documentation and access to APIs that make source code more usable or, even better, somewhat meaningless. Cloud computing already obviates much of the value of source-code access, a trend that I believe we'll continue to see as users demand the transparency of open source without having to muck in the code.
Such a trend is a useful "next-generation open source" because it focuses on users, not developers, with data, not code, the primary currency. So, while I'm glad to see the GIMP project discussing usability enhancements, I'd much rather see such projects finding ways to include average users in the process of development.
This has long been a weakness of OpenOffice.org, for example. I doubt most of OpenOffice.org developers do a lot of presentations, spreadsheets, and such. But the target user--someone like me--is mostly locked out of the development process by unfamiliarity with the project and no clear idea as to how to help.
Meanwhile, proprietary software like Lose It! and other social software does a far better job of including users in the "development" process by making development all about data, not source code.
In sum, proprietary software has much to learn from open source, and is increasingly applying open-source lessons of transparency and modifiability. But open source also has a lot to learn from the proprietary software world, which increasingly involves lay users in a way that open source has not.
Follow me on Twitter @mjasay.
Matt Asay brings a decade of in-the-trenches open-source business and legal experience to The Open Road, with an emphasis on emerging open-source business strategies and opportunities. Matt is vice president of business development at Alfresco, a company that develops open-source software for content management. He is a member of the CNET Blog Network and is not an employee of CNET. Disclosure. You can follow Matt on Twitter @mjasay. 
mySql just got killed.. and Apache isn't that popular after all--- I think that IIS is the clear winner in mindshare / marketshare.
what else is there.. PHP? Php runs fastest on IIS 7.0!!!
-Aaron
What are you smoking?
PHP is a crap language not fit for use of any kind, not even on a crappy Windows server.
Matt, I admire the frequency of your posts, but sometimes you need to do a bit more homework.
There's not much point trying to modify executables (unless you're a cracker) - it's very difficult and the resultant code will only run on a specific platform. All innovation in software comes from modifying *source* code.
I'm not arguing that source code is irrelevant. I'm just saying it's not omnipotent.
Not a big deal though, we'll all live.
The license is forefront like the US Constitution is forefront in being a citizen. I may not exercise all my rights in a given day, or even a given year, but when I do need them, I'm more glad I have them than all the pseudo-openness of e.g. an electoral college or state initiative process.
These closed apps with open APIs, etc., are just sucking users in. If history is any indicator, they will turn against the user in the end. Why? Because people, especially business people, are greedy. Without a constitution or license to fall back on, it's hard to feel that all people will act with good faith once they have us locked in to using their open-but-not-free APIs.
As a developer who has experienced frustration with the opaqueness of both proprietary and open source software I can definitely relate to your point about how a well designed and documented API for a proprietary library or application trumps a tarball of source code.
All other things being equal, it's always better for both users and developers to have the source code to the software they use. Computer software is still a very new human endeavor though and we are still experimenting with different social structures to produce better software and make it available to more people.
I'm sorry that so much ideology gets in the way of having a sincere conversation about what really matters. Thank you for stepping into the firing line (for this community at least) and expressing some important ideas.
An open app is far more useful than an open API, but the latter is nice as well.
Also, it would be good if "users" can be given some "convenient" way to review/give feedback about usability and functionality of open source projects.
Thanks.
- by mpdehaan May 31, 2009 4:13 PM PDT
- Matt,
- Like this Reply to this comment
-
(16 Comments)You've quoted me out of context again. I suggest you re-read it.
My blog post was about how to get better mileage out of OSS communities and where folks need to concentrate harder and you somehow thought it's about proprietary software and just working with users and not developers. Sorry, that's just not very open at all. Please don't force those words into my mouth.
How was the post intended? Lots of new folks getting into project maintaince don't know all the magic behind community management, so they don't know where to focus. It's not an issue of something sucking, rather an issue of "these are things you should be aware of and work to make better". See how nearly every paragraph ended with a way to improve things?
I'm infinitely more amazed by the capabilities of open development every single day. However, I look at many projects (ones that trend towards closedness or are half-open) and I am sad. I wrote that article showing people how to focus and understand some of the things the needed to do, so they could truck on and understand. I look at many big-name ISV projects as I see them fail to leverage the community in ways that Fedora and Debian have done. I want to help them, which is why I wrote that blog post. To let them know where they have to work at it.
Since you've linked to me a little, perhaps you would like to read this instead and post how well your projects fit the criteria. I think that would be interesting!
http://michaeldehaan.net/2008/07/29/how-open-source-is-your-open-source/