Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Get HideMyAss! VPN, PC Mag's Top 10 VPNs of 2016 for 55% off for a Limited Time ×
Open Source Programming Software

Open Source Roles: Starters vs. Maintainers (jlongster.com) 77

An anonymous reader writes: Mozilla developer James Long has posted a sort of internal monologue on the difficulties of being a hobbyist open source project maintainer. He says, "I hugely admire people who give so much time to OSS projects for free. I can't believe how much unpaid boring work is going on. It's really cool that people care so much about helping others and the community. ... There are two roles for any project: starters and maintainers. People may play both roles in their lives, but for some reason I've found that for a single project it's usually different people. Starters are good at taking a big step in a different direction, and maintainers are good at being dedicated to keeping the code alive.

I am definitely a starter. I tend to be interested in a lot of various things, instead of dedicating myself to a few concentrated areas. I've maintained libraries for years, but it's always a huge source of guilt and late Friday nights to catch up on a backlog of issues. ... Here's to all the maintainers out there. To all the people putting in tireless, thankless work behind-the-scenes to keep code alive, to write documentation, to cut releases, to register domain names, and everything else."

This discussion has been archived. No new comments can be posted.

Open Source Roles: Starters vs. Maintainers

Comments Filter:
  • I'm not sure this is accurate. If it were, why would anyone choose to be a maintainer, stuck fixing small bugs for years on end and having little to do with the movements forward?
    • by Anonymous Coward

      Well, I do both. I maintain a few packages in a fairly popular GNU distribution. It can take some time but I have plenty left for working on my own projects and contribute to a number of upstream projects that I'm interested in. It takes some planning though. I've always been fascinated by how much time a lot of people just throw away.

    • There are a lot of degrees on the autism spectrum, look at Wikipedia.

    • by Kjella ( 173770 ) on Wednesday December 30, 2015 @01:08PM (#51209507) Homepage

      I'm not sure this is accurate. If it were, why would anyone choose to be a maintainer, stuck fixing small bugs for years on end and having little to do with the movements forward?

      Hardly anybody starts as a maintainer, it just creeps up on you. Like some years ago I was busy trying to get some games to work under WINE, filed some bug reports and found various tweaks to make them work. Since there wasn't a maintainer in the appdb, I signed up. And then it just became a habit to fire up the games when new versions came out, even some I'd grown tired of just to check that it was still working or if there were regressions, if the tweaks were still necessary and so on. Once they totally broke some games and I bisected it back to the commit and it got fixed. Maintenance is what keeps things working, you do it a little bit for yourself and a little bit for the public good.

    • by Anonymous Coward

      I tend to take on the maintainer role. A lot.

      What I usually find is someone creates a tool/game/daemon I find useful. I start using it and submitting feature requests or bug reports. Then the original developer reports they are not longer working on the project or don't have time to address bug reports.

      I end up patching the software and maintaining it for myself and publishing the code for others to use. Then people start e-mailing me and asking me to fix other bugs or add a new feature or port the software

    • by Anonymous Coward

      I'm not sure this is accurate. If it were, why would anyone choose to be a maintainer, stuck fixing small bugs for years on end and having little to do with the movements forward?

      Craftsmanship.

      One of the things that really hurt Apple was after I left, John Sculley got a very serious disease. And that disease—I've seen other people get it, too—it's the disease of thinking that a having a great idea is really 90 percent of the work. And if you just tell people, 'here's this great idea,' then of course they can go off and make it happen. The problem with that is that there's a tremendous amount of craftsmanship between a having a great idea and having a great product.

  • plenty of people get paid to "do open source". plenty of people even contribute and maintain while on company time because their company lets them be involved. others do it anyway on the clock because it's the same as being on slashdot at work only of more benefit to others (tsk tsk, shocking I know). speaking of which, back to work for my lazy self....and later I'm going to do a commit to something at least a quarter of you all use, even though my employer might not appreciate that. shame for same...

    • I have seen submissions written on company time at the company request because it fixed something for them. And once accepted, it was now supported. :) They like that!
  • ...which is why open source and Linux have worked so well together over the years. Most specifically, Linux has always been about "do one small thing but do it well" so the "10 starters to 1 maintainer" ratio in the open source community works.

    • Want to muscle your way into an OSS project, despite lacking the talent or skill (or willingness) to contribute anything other than drama, identity politics, and an insatiable urge control others (or remove them if they don't fall in line)? Force a Code of Conduct (which is often explicitly racist and/or sexist, dismissive of merit, and vague enough to be selectively enforced) down its throat! It even works on the largest projects!

      https://www.reddit.com/r/Kotak... [reddit.com]
      https://www.reddit.com/r/Kotak... [reddit.com]
      h [todogroup.org]
      • by Boronx ( 228853 )

        What's sad is that so many need these codes to remind them to act civil. If you're smart enough to contribute to FreeBSD, you should be smart enough to not act like an asshole.

  • Everybody wants the cool job of being one of the original coders. Nobody wants the not-so-cool job of actually maintaining it over the long-term, writing documentation for it, supporting it, etc. That's what often separates the OSS stuff from the commercial stuff, especially over the long-haul (and why companies are willing to spend extra money on commercial, proprietary software even when an OSS alternative exists).

    • by MacDork ( 560499 )

      Everybody wants the cool job of being one of the original coders. Nobody wants the not-so-cool job of actually maintaining it over the long-term, writing documentation for it, supporting it, etc.

      I don't see it that way at all. I find that the maintainers are there because the code is useful to them. It's far easier to take what's there and fix a few bugs than start a whole new version just for the sake of having written it yourself.

      Sometimes starting a project is simply implementing something from one language in another. The 'starter' is only interested in getting it to the "good enough" stage that he can use it. I don't consider that cool at all. That's just work. And the starter is just a porter

    • by Kjella ( 173770 )

      Everybody wants the cool job of being one of the original coders. Nobody wants the not-so-cool job of actually maintaining it over the long-term, writing documentation for it, supporting it, etc. That's what often separates the OSS stuff from the commercial stuff, especially over the long-haul (and why companies are willing to spend extra money on commercial, proprietary software even when an OSS alternative exists).

      I think that's very variable, there is a lot of proprietary code that happens to solve their one particular use case as long as you use it exactly that way, but if you want to use it some other way you can't. Open source is used by many different people with many different needs so you usually get flexible solutions. Like for example WordPress has become the most popular CMS because it can morph into almost anything. Linux runs on everything from cell phones to supercomputers. Long haul you very rarely see

    • Nobody wants the not-so-cool job of actually maintaining it over the long-term, writing documentation for it, supporting it, etc.

      This right here! You want to learn a new bit of software and get the attention of the dev team? While learning, write new user documentation. You will have the dev team's full and undivided attention! I know a lot of project leads that started by writing documentation for another project.

      • Nobody wants the not-so-cool job of actually maintaining it over the long-term, writing documentation for it, supporting it, etc.

        This right here! You want to learn a new bit of software and get the attention of the dev team? While learning, write new user documentation. You will have the dev team's full and undivided attention! I know a lot of project leads that started by writing documentation for another project.

        My personal take on this is that if you need to read documentation in order to be able to use a piece of software, something is wrong with that piece of software, and it's not a lack of documentation. One of the reasons there are no "themes" in Mac OS X is that it means that the answer to the question of "how do I throw something away" is always the same. And if the application follows the style guidelines, then you can transfer your knowledge easily between applications.

        I blame Bob Wallace, and PC-Write.

        • That's crap.

          I used to amuse myself by figuring out the finer points of a software configuration (or lack thereof, or whether there's a bug) by autodidactic reasoning. But these days, I just don't have the time to spend, aka waste, by screwing around. So I really appreciate well-organized docs, especially with good examples that get right to the point.

          Getting a project into operation may take a bunch of standard activities, as well as - lets say, 100 non-obvious actions. If well-organized docs provide a 2-mi

        • Try doing something even moderately sophisticated in either Photoshop or gimp, without a manual or prior knowledge. What the hell is a channel? A path? A layer?

          It's not necessarily a defect of the software. Some ideas and procedures are too inherently complicated to be handled by a newbie without a lot of difficulty.

  • I have found this to be very true outside of Open Source as well.

    Some people thrive on pressure, deadlines, designing and building things that are hard to design and build, working in teams solving tough problems. Those people get bored when the SW project goes into maintenance mode. Others don't thrive with all that. They want to, or are at least willing to work at a different pace, with different kinds of challenges, reverse engineer other people's work, make bug fixes or incremental improvements under

  • the arrogance behind being a "starter" is staggering. i group it in the same category as the "entrepreneurs" who hold meetings at the startup incubators about how they successfully started 47 businesses and sold them off to get rich. basically they had an idea, tricked a bunch of saps to do it for them, sell both the product and the saps off, and then repeat. i find this one of the lowest forms of humanity. pick some shit you love and stick with it. stop screwing everyone around you so you can build more ma

    • by KGIII ( 973947 )

      What's wrong with being the starter and getting things in motion and then going on to a new and different thing? You explained that you didn't like it - you didn't tell us why and why it is a problem. It's a nice rant, and all, but it doesn't actually explain why you're ranting.

      I "started" something. In fact, I was on the cusp of something that turned out to be pretty huge, at least for a while. I then owned and worked at that company for more than 15 years before I sold it. Selling it was actually a little

      • comment #51211381 by anon is very well put that describes whatever was missing for your understanding. starters pollute the startup-funding meetings with their deceptions. it's pretty easy to tell even before the floor is theirs to talk - giving off that classic snake oil salesman vibe.
        • by KGIII ( 973947 )

          That seems like it's a rather large brush to paint with. I'm not sure if it is worth the energy and time (time being my most precious asset) but I'll take a chance.

          Allow me, if you will, to give an example or three:

          I have a friend, near and dear to my heart, and he owns/operates a small franchise fast-food outlet in a small town called Farmington, Maine. He employs a few people, mostly cute college girls, to work at the counter making sandwiches. There is a manager and an assistant manager. The hourly rate

  • Only do the fun part (Score:4, Interesting)

    by DNS-and-BIND ( 461968 ) on Wednesday December 30, 2015 @01:34PM (#51209649) Homepage

    So why would anyone want to do the boring part of programming? Stay with the fun part, starting projects! Then, when it's 90% done, abandon it and let the next idiot take it over. I've known so many good ideas that were never finished, and the creator not only declines to continue, but angrily rejects the idea that she should be forced to finish what she started.

    I've seen this happen so many times, and the key idea here is novelty. Doing something new. It's the short attention span that demands a constant flow of shiny trinkets, each different from the last. It's bizarre seeing that a core idea of the engineering mindset, and programmers as a subset of that is (or was) damn the torpedoes, full speed ahead. Seeing an idea through to completion no matter what obstacles appear. In fact, overcoming those obstacles and finishing the project, whatever it might be, is (used to be) a great source of pleasure and pride.

    Indeed in this very thread I am seeing people who have no conception of finishing projects and are baffled that anyone might want to do anything but the fun part. That's the part that hurts - not that different perspectives exist, but that these diverse perspectives have no intellectual space to recognize that alternate ideas even exist, and regard those who think differently as weirdos. :(

    • Re: (Score:2, Troll)

      /sarcasm Hey, that's why I have a *tons* of small GitHub projects. :-)

      On a more serious note the greatest skill a programmer can have is:

      *Ship* the dam thing!

      I agree maintaining an open source project is definitely not as "sexy" as writing brand spanking new code but a *balanced* programmer is a great programmer; one who cares about quality of everything, from code, to docs, to examples, to test cases, to bugs, to support, etc.

    • define: hobby
      an activity done regularly in one's leisure time for pleasure.

      I'm pretty sure that if you're a hobbyist programmer and you're not doing it for pleasure then you're doing it wrong. Or a masochist.

      And they're right to angrily reject the idea that they should be forced to finish it. Because it's a hobby.

      If anyone disagrees then they can have fun and fork it themselves and finish it. And maybe leave a note in thanks for the 90% that was written for them.
      Github makes this so easy that it amazes me t

    • If you find yourself being the primary (or only) maintainer of a package, it really belongs to you, doesn't it? You can fork and rename it, continue maintaining only the new fork, and voila! It's yours.

  • Some folks have a lot of fun making children.
    Other folks have a lot of fun raising children.

    There are a lot of software deadbeat dads. Good luck getting them to take care of what they've created.
    • Some folks have a lot of fun making children.
      Other folks have a lot of fun raising children.

      I'm pretty sure most people have fun making children and many people find satisfaction in raising children - fun for the latter is often just a rare bonus that varies with the age, mood, (etc) of the child and the current state of your relationship with said child.

  • People who start new businesses are rarely good at maintaining and growing them once they have taken off. They are the people with the vision and foresight, not the ones with the ability to manage people and deal with politics.

    Any software project, open source or otherwise, could be seen as an enterprise. There are a few people who can both start and maintain a business, or a project, but not many.

  • I wrote this paper nine years ago. Go to http://vulpeculox.net/ob/index... [vulpeculox.net] and follow the link to The future of collaborative software development

    One of the key ideas is that a theatre company has all sorts of skills unrelated to acting or play-writing. A collaborative software project should be half a dozen people at a minimum. Once the group has 'done' one project it'll soon find something else to work on, whether extending the objectives, enhancing the deliverable or something completely different.

    I have a dozen FOSS contributions on my web site but I just don't want to get into the hassle of Git or licensing or selling or even promotion. I'm an inventor not a financier or sales executive!

  • by mveloso ( 325617 ) on Wednesday December 30, 2015 @04:06PM (#51210853)

    In real life, people who start projects aren't as import and you'd think.

    Who fixes the bugs and gets things to work? Maintainers.
    Who fixes the fucked up architecture? Maintainers.
    Who does the incremental improvements that make software better? Maintainers.
    Who cares that the software actually does what it's supposed to? Maintainers.

    The difference between starters and maintainers is the difference between a sperm donor and a dad. Without maintainers there would be no good software, because starters generally don't make good software - they make software that does one thing.

    As anyone who does this for a living knows, it's the execution that matters, not the ideas.

  • It's not divided that way.

    It's not "starters" vs. "maintainers", it's "Mr. Right Now" vs. "Mr. Right" (or Ms.).

    Your "Right Now" person gets you a prototype, and gets you to funding.
    Your "Right" person gets you to a million customers, because when you ship in volume, that shit can't break.

    It's all about "the reason you get the big bucks is because you do the un-fun stuff that means you own the 'It Works' bit". Someone has to own the "It Works" bit, and set that bit before you ship a steaming pile to a bunch

  • Yes, to all who maintain open source projects, thank you, thank you, thank you. Especially the Mozilla team, I use Firefox and Thunderbird everyday.
  • In my company, we sometimes use open source software as part of a deliverable.
    Sometimes we find bugs in parts that are that are important for our use, so we fix them, and try to work with the community to integrate the patch. We don't do this because we are generous, we do this because we don't want to maintain a fork. That others can benefit from our work is a happy side effect.
    This make us maintainers, probably like many others.

Those who can, do; those who can't, write. Those who can't write work for the Bell Labs Record.

Working...